Please type a plus sign (+) inside this box | + | 



3 Under the Paperwork Reduction Act of 1995, no persons are required to respond to a collection of information unless it displays a valid 0MB control number. 



PTO/SB/05 (12/97) 
Approved for use through 09/30/00. 0MB 0651-0032 
Patent and Trademark Office: U.S. DEPARTMENT OF COMMERCE 



UTILITY 
PATENT APPUCATION 
TRANSMITTAL 

(Only for new nanprovlsional apptications under 37 CFR 1.53(b)) 



Attorney Docket No. 


GEMS:0029 
15-SV'4769 


Total Pages 


107 


First Named lnver)tor or Application Identifier 
Kenneth Lawrence Accardi 






Express Mail Label No. 


1 EL066000575US 





APPLICATION ELEMENTS 

See MPEP chapter 600 concerning utility patent application contents. 



ADDRESS TO: 



Assistant Commissioner for Patents 
Box Patent Application 
Washington, DC 20231 



O 



Fee Transmittal Form 

(Submit an original, and a duplicate for fee processing) 
Specification Total Pages : 51 
(preferred arrangement set forth below) 
-Descriptive 

-Cross References to Related Application 

-Statement Regarding Fed sponsored R&D 

-Reference to Microfiche Appendix 

-Background of the Invention 

-Brief Summary of the Invention 

-Brief Description of the Drawings (if fifed) 

-Detailed Description 

-Claim{s) 



6. □ Microfiche Computer Program (Appendix) 

7. Nucleotide and/or Amino Acid Sequence Submission 
(if applicable, all necessary) 

a. □ Computer Readable Copy 

b. □ Paper Copy (identical to computer copy) 

c. □ Statement verifying identity of above copies 







ACCOMPANYING APPLICATION PARTS 


3. S 


Formal Drawing(s) (35 USC 113} Total Sheets: 17 


8. 


□ 


Assignment Papers (cover sheet & document(s)) 




Total Pages: 51 












9. 


□ 


37 CFR 3.73(b) Statement S Power of Attorney 










(where there is an assignee) 


4. Oath or Declaration 


10. 


□ 


English Translation Document (if applicable) 


a. 


S Newly executed (original or copy) 


11. 


□ 


Information Disclosure □ Copies of IDS 


b. 


□ Copy from a prior application (37CFR 1 .63(d)) 






Statement (IDS)/PTO-1449 Citations 




(for coniinuation/divisionaf with Box 17 completed) 










[Note Box 5 below] 










\. n DELETION OF INVENTOR(S) 


12. 


□ 


Preliminary Amendment 




Signed statement attached deleting 










inventor(s) named in the prior application, 










see 37 CFR 163(d)(2) and 1.33(b). 












13. 




Return Receipt Postcard (MPEP 503) 


5. □ 


Incorporation By Reference (useable if box 4b is ched(ed) 


14. 


□ 


Small Entity □ Statement filed in prior application 




The entire disclosure of the prior application, from which a 






Statement(s) Status still proper and desired 




copy of the oath or declaration is supplied under Box 4b, 










is considered as being part of the disclosure of the 










accompanying application and is hereby incorporated by 










reference therein. 












15. 


□ 


Certified Copy of Priority Document(s) 










(if foreign priority is claimed) 






16. 


□ 


Other 


17. □ 


Continuation □ Divisional 


□ Continuation-in-part (CIP) of prior apolication No' / 



18. CORRESPONDENCE ADDRESS 



□ Customer Number or Bar Code Label 



Correspondence address below 



(Insert Customer No. or Attach barcode label here) 



NAME 



Patrick S. Yoder 



Fletcher, Yoder & Van Someren 



ADDRESS 



P.O. Box 692289 



I ZIP CODE I 77269-2289" 



CITY 



Houston 



I STATE Texas 



I TELEPHONE 



COUNTRY 



USA 



(281)970^545 



Fax 



(281)970-4503 



Burden Hour Statement: This form is estimated to take 0.2 hours to complete. Time wit! vary depending upon the needs of the individual case. Any 
comments on the amount of time you are required to complete this forni should be sent to the Chief Information Officer, Patent and Trademark 
Office, Washington, DC 20231. DO NOT SEND FEES OR COMPLETED FORMS TO THIS ADDRESS. SEND TO: Assistant Commissioner for 
Patents, Box Patent Application, Washington, DC 20231, 



PTO/SB/17 (10/96) 
Approved for use through 09/30/98. 0MB 0651-0032 
Patent and Trademark Office: U.S. DEPARTMENT OF COMMERCE 



FEE TRANSMITTAL 


Complete if Known 


ADDlication Number 


unassigned 


Filing Date 


11/25/98 


First Named Inventor 


Kenneth Lawrence Accardi 


Group Art Unit 


unknown 


Examiner Name 


unknown 


TOTAL AMOUNT OF PAYMENT 


($) 1,426.00 


Attorney Docket Number 


GEMS:0029/15-SV-4769 



METHOD OF PAYMENT (check one) 



FEE CALCULATION (continued) 



1 . ^ The Commissioner is hereby auttiorized to charge indicated 
fees and credit any over payments to* 

Deposit 07-0845/GEMS: 0029/1 5-SV-4769 

Account 
Nunnber 

Deposit 
Account 
Name 



3. ADDITIONAL FEES 



GE IVIedical Systenns 



^ Charge Any Additional 
Fee Required Under 37 
CFR 1.16 and 1.17 



I I Charge the Issue Fee Set in 37 
CFR 1.18 at the Mailing of the 
Notice of Allowance, 37 CFR 
1.31(b) 



2. O Payment Enclosed: 

□ Check □ Money Order □ Other 

FEE CALCULATION (fees effective 1 1/10/98) 



1. FILING FEE 



Large Entity 




Small Entity 




Fee Fee 
Code ($) 




Fee 
Code 


Fee 
{$) 


Fee Description 


101 760 




201 


395 


Utility filing fee 


106 330 




206 


165 


Design filing fee 


107 540 




207 


270 


Plant filing fee 


108 790 




208 


395 


Reissue filing fee 


114 150 




214 


75 


Provisional filing fee 
SUBTOTAL (1) 


2. CLAIMS 




Extra 


Fee from 
below 


Total Claims 


44.-20 = 


24 


X 18 = 


Independent _ 
Claims 


6 - 


3 = 


3 


X 78 = 


Multiple Dependent Claims 




X 


Large Entity 




Small Entity 




Fee Fee 
Code ($) 




Fee 
Code 


Fee 

($) 


Fee Description 


103 18 




203 


11 


Claims in excess of 20 


102 78 




202 


41 


independent claims in 
excess of 3 


104 270 




204 


135 


Multiple dependent claim 


109 82 




209 


41 


Reissue independent 
claims over original patent 


110 22 




210 


11 


Reissue claims in excess of 



Fee Paid 



760 00 



($) 760.00 



Fee Paid 



432 00 
234 00 



of 20 and over original patent 
SUBTOTAL (2) ($) 666.00 



Large 

Fee 

Code 


Entity 

Fee 

($) 


Small 
Fee 
Code 


Entity 

Fee 

($) 


105 


130 


205 


65 


127 


50 


227 


25 


139 


130 


139 


130 


147 


2,520 


147 


2,520 


112 


920* 


112 


920* 


113 


1,840* 


113 


1,840* 


115 


110 


215 


55 


1 ID 


Ann 


^ 1 D 


9nn 


1 1 / 


yov 


1 / 


*t/ O 


118 


1,570 


218 


755 


119 


310 


219 


155 


120 


310 


220 


155 


121 


270 


221 


135 


138 


1,510 


138 


1,510 


140 


110 


240 


55 


141 


1,320 


241 


660 


142 


1,320 


242 


660 


143 


450 


243 


225 


144 


670 


244 


335 


122 


130 


122 


130 


123 


50 


123 


50 


126 


240 


126 


240 


581 


40 


581 


40 


146 


790 


246 


395 


149 


790 


249 


395 



Fee Description Fee Paid 

Surcharge - late filing fee or oath 

Surcharge - late provisional filing 

or cover sheet 

Non-English specification 

For filing a request for 

reexamination 

Requesting publication of SIR 

pnor to Examiner action 

Requesting publication of SI R 

after Examiner action 

Extension for response 

within first month 

Extension for response 

within second month 

Extension for response 

within third month 

Extension for response 

within fourth month 

Notice of Appeal 

Filing a brief in support 

of an appeal 

Request for oral hearing 

Petition to institute a public 

use proceeding 

Petition to revive unavoidably 

abandoned application 

Petition to revive unintentionally 

abandoned application 

Utility issue fee (or reissue) 

Design issue fee 

Plant issue fee 

Petitions to the Commissioner 

Petitions related to provisional 

applications 

Submission of Information 

Disclosure Stmt 
Recording each patent 
assignment per property {times 
number of properties) 

Filing a submission after final 

rejection (37 CFR 1.129(a)) 

For each additional invention 

to be examined 
(37 CFR 1 129(b)) 



Other fee (specify) 

Other fee (specify) 

SUBTOTAL (3) 

* Reduced by Basic Filing Fee Paid 



($) 



SUBMITTED BY 












Complete (if applicable) 


Typed or Printed Name 


Patrick S. Yoder 


Reg. Number 


37,479 


Signature 





Date 


November 25, 
1998 


Deposit Acct User 
ID 


07-0845/GEMS:0029/1 5-SV- 
4769 



H: 228568(FEE TRANSMITTAL for Gems0029 doc doc) 



GEMS:0029 
15-SV-4769 



MEDICAL DIAGNOSTIC SYSTEM 
SERVICE METHOD AND APPARATUS 



by 

Kenneth Lawrence Accardi 
Deborah A. Babula 
George Peter Gesior 
Henry John Hummel, Jr. 
lanne Mae Howards Koritzinsky 
Scott Matt McOlash 
George Tzortzos 
Hubert A. Zettel 





■personal^ depositing M is pap^r^ca 




'datfifidic&id^af^'^ iri^a sealed ei 


07i the 

tyelope fyi) ^h(^irig'the above- 


nitmBet'edMxpres^:M 
, (h) addr essed to t^^^ 


missionerfif^.J^at^^ 






Si^atm-eSt^i^J^C^^ 




\ Wriht0Mgme: KimMennessi^ r^y. (r -;r;-i5;i \ ■ ' n! ii W^i^^^^t V-^;::-! ■ ^ : 



GEMS:0029 
15-SV-4769 



MEDICAL DIAGNOSTIC SYSTEM SERVICE 
METHOD AND APPARATUS 

5 FIELD OF THE INVENTION 

The present invention relates generally to the field of medical diagnostic 
and imaging systems. More particularly, the invention relates to interactive 
servicing of such systems, such as via remote service facilities, in which system 
configurations, image data and other files, protocols, service requests, reports and 
10 other useful information can be exchanged interactively between a remote service 

facility and the diagnostic system. 

BACKGROUND OF THE INVENTION 

Medical diagnostic and imaging systems are ubiquitous in modem health 
15 care facilities. Such systems provide valuable tools for identifying, diagnosing and 

treating physical conditions and greatly reduce the need for surgical diagnostic 
intervention. In many instances, final diagnosis and treatment proceed only after an 
attending physician or radiologist has complemented conventional examinations 
with detailed images of relevant areas and tissues via one or more imaging 
20 modalities. 

Currently, a number of modalities exist for medical diagnostic and imaging 
systems. These include computed tomography (CT) systems, x-ray systems 
(including both conventional and digital or digitized imaging systems), magnetic 

25 resonance (MR) systems, positron emission tomography (PET) systems, ultrasound 

systems, nuclear medicine systems, and so forth. Li many instances, these 
modalities complement one another and offer the physician a range of techniques for 
imaging particular types of tissue, organs, and physiological systems and 
phenomena. Health care institutions often dispose of several such imaging systems 

30 at a single or multiple facilities, permitting its physicians to draw upon such 

resources as required by particular patient needs. 
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Modem medical diagnostic systems typically include circuitry for acquiring 
image data and for transforming the data into a useable form which is then processed 
to create a reconstructed image of features of interest within the patient. The image 
5 data acquisition and processing circuitry is often referred to as a "scanner" 

regardless of the modality, because some sort of physical or electronic scanning 
often occurs in the imaging process. The particular components of the system and 
related circuitry, of course, differ greatly between modalities due to their particular 
physics and data processing requirements. 

10 

Medical diagnostic systems of the type described above are often called 
upon to produce reliable and understandable images within demanding schedules 
and over a considerable usefiil life. To ensure proper operation, the systems are 
serviced regularly by highly trained personnel who address imaging problems, 

15 configure and calibrate the systems, and perform periodic system checks and 

software updates. Moreover, service offerings have been supplemented in recent 
years by remote service centers capable of contacting scanners at subscribing 
institutions directly without the need for intervention on the part of the institution 
personnel. Such remote servicing is intended to maintain the diagnostic systems in 

20 good operational order without necessitating the attention of physicians or 

radiologists, and is often quite transparent to the institution. 

While such service techniques have proven extremely valuable in 
maintaining diagnostic systems, fiirther improvements are still needed. For 

25 example, in conventional service systems, contact between the scaimers and a 

centralized service center most often originates with the service center. The 
scanners are provided with only Hmited fimctionality in the abihty to identify and 
define service needs. Even where the scanners have permitted some limited abihty 
to contact networked service providers, intermittent conditions indicative of a 

30 potentially serviceable problem may cease by the time the service provider is 

contacted or recontacts the scanner after a service call. Moreover, although the 
transparency of interactions between scaimers and service centers avoids 
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unnecessarily distracting medical personnel with service updates, it has become 
apparent that some degree of interaction between service centers and institutions 
would be highly desirable. In particular, an interactive service system would 
facilitate valuable exchanges of information, including reports of system 
5 performance, feedback on particular incidents requiring attention, updates of system 

hcenses, software, imaging protocols, and so forth. Currently available service 
systems do not permit such interactive exchanges. 

In addition to the foregoing drawbacks, conventional scanners are not 
10 suitably adapted to support user-fiiendly, scanner-based service exchanges. User 

interfaces in such scanners typically only permit limited access to service 
3 information, and do not provide a particularly usefiil interface for identifying and 

^ defining serviceable conditions as they occur. Moreover, software platforms and 

% interfaces in conventional scanners are not suitable for interaction with service 

J 15 centers, and generally exclude the user from communications between the scanner 

1 and the service center or, conversely, impose unnecessarily on the user by requiring 

intervention for certain service fimctions such as software updates or downloads. 
^ Furthermore, platforms have yet to be developed that can serve as a basis for 

^ interactive servicing needs of different modalities. Rather, such platforms have 

^ 20 traditionally been specifically designed for the needs of a particular modality or even 

a particular scanner with little cross utility between systems or modalities. 

While improvements in diagnostic stations has been made for certain 
modalities, these are still insufficient to satisfy the current need. For example, 

25 graphical user interfaces are available for specific modality scanners, such as 

ultrasoxmd scanners, which enable software downloads and remote access to images. 
The remote access features are, however, generally limited to transmitting image 
configurations and image data for reconstruction between remote physician 
workstations and the scanner. At present, available systems do not provide for 

30 exchanging information on possible service problems with the scanners, or 

information or data log files for the purpose of providing remote service of the 
scanner itself 
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SUMMARY OF THE INVENTION 

The present invention provides an interactive servicing technique for 
medical diagnostic equipment designed to respond to these needs. The technique 
5 offers a straightforward and user-fiiendly environment for identifying and requesting 

service for potential problems occurring at the scanner, which may be either 
recurring in nature or intermittent. The technique may be apphed on a variety of 
scanner modalities, and offers a uniform interface, platform and system architecture 
across modalities. Thus, the system may be easily adapted to permit a remote 

10 service center to provide high quality service to various diagnostic equipment 

regardless of the modality, model or even the manufacturer. Moreover, a wide array 
of service functions may be incorporated into systems based upon the technique. 
For example, service functions such as imaging system trouble shooting and 
exchange of service call requests and results may be a basic feature provided in the 

15 systems, hi addition, messaging functions permitting two-way communication 

directly from the scanner or from a centraHzed radiology management station at an 
institution are facilitated. Such messaging may be used for communicating the 
requests and service call results, providing reports on both technical and business or 
financial data, reviewing, renewing or extending licenses, updating or downloading 

20 new system software and imaging protocols, accessing remote training schedules 

and programs, and so forth. 

In a presently preferred system architecture, the technique provides an 
interactive interface installed at the scanner. The interface permits the user to 
25 navigate through pages for identifying and reporting serviceable problems at the 

scanner. The interface also may permit the user to request information such as 
training programs, software updates, imaging protocols, and so forth. 

Service requests and other messages from the scanner are transmitted to a 
30 centraUzed service center via a remote networking system, such as an intranet or 

intemet. The service center receives such messages and interacts with the scanner to 
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inform the scanner that the request has been received and is being processed. The 
software platform at the scanner then faciUtates the exchange of image and other file 
data with the remote service center for analysis of system parameters, imaging 
problems, and so forth. Results of the analyses can then be transmitted directly to 
5 the scanner to inform the institution of the causes and possible corrective actions. 

The system also allows the service center to execute proactive or reactive 
sweeps of scanners to collect information useful to analyze the performance of the 
scanner as well as to compare its performance to that of other scanners. Moreover, 
10 such sweeps may be used to collect information useful in predicting future service 

needs, such as x-ray tube replacement and so forth. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a diagrammatical representation of a series of medical diagnostic 
15 systems coupled to a service facility via a network connection for providing 

remote service and data interchange between the diagnostic systems and the 
service facility; 

Fig. 2 is a block diagram of the systems shown in Fig. 1 illustrating certain 
functional components of the diagnostic systems and the service facility; 
20 Fig. 3 is a block diagram of certain functional components within a 

diagnostic system of the type shown in Fig. 1 and Fig. 2 for facilitating interactive 
remote servicing of the diagnostic system; 

Fig. 4 is a block diagram of certain of the functional components of the 
service faciUty illustrated in Fig. 1 and Fig, 2 for rendering interactive remote 
25 service to a plurality of medical diagnostic systems; 

Fig. 4(A) and 4(B) illustrate sub-components for license and report servers 
included in the processing system shown in Fig. 4; 

Fig, 5 is a block diagram of functional components within a field service 
unit which can be coupled to the diagnostic systems and to the service facility for 
30 exchanging service information with a field service engineer; 
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Fig. 6 is an exemplary user interface page incorporated in the diagnostic 
system for placing service requests, and sending and receiving service data 
between the diagnostic system and a remote service facility; 

Fig. 7 is a second user interface page for conveying service information to 
5 the scanner operator from the service facility; 

Fig. 8 is an interface page for generating a particular type of service 
request at the scanner and for conveying the service request to the service facility; 

Fig. 9 is an interface page for requesting, compiling and transmitting 
reports regarding service activities provided by the service facility to the scanner; 
10 Fig, 10 is an interface page for transmitting and viewing service-related 

messages from the service facility at the scanner; 

Fig, 11 is an interface page including descriptions of software routines, 
such as imaging protocols, at the diagnostic system scanner which are installed at 
the scanner or available from a service facility or library; 
15 Fig. 12 is a flow chart illustrating exemplary logic implemented by the 

diagnostic systems for requesting one type of analysis and service from a remote 
service facility; 

Fig. 13 is a flow chart illustrating exemplary logic in handling such service 
requests by the service facility; 
20 Fig. 14 is a flow chart illustrating exemplary logic for reporting service 

activities, updates, alerts, and so forth from the service facility to a diagnostic 
system; 

Fig. 15 is a flow chart illustrating exemplary logic for verifying and 
controlling financial and management arrangements between the service facihty 
25 and the diagnostic systems, such as licensing arrangements, subscription 

arrangements, pay-per-use arrangements, and so forth; and. 

Fig, 16 is a flow chart illustrating exemplary control logic for accessing 
diagnostic protocols both from a local storage source at the diagnostic system, as 
well as from a remote library. 

30 
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DETAILED DESCRIPTION OF THE INVENTION 

Turning now to the drawings, and referring first to Fig. 1, a service system 
10 is illustrated for providing remote service to a plurality of medical diagnostic 
5 systems 12. In the embodiment illustrated in Fig. 1, the medical diagnostic systems 

include a magnetic resonance imaging (MRI) system 14, a computed tomography 
(CT) system 16, and an ultrasound imaging system 18, The diagnostic systems may 
be positioned in a single location or facility, such as a medical facility 20, or may be 
remote fi-om one another as shown in the case of ultrasound system 18. The 
10 diagnostic systems are serviced fi-om a centralized service facility 22. Moreover, a 

plurality of field service units 24 may be coupled in the service system for 
transmitting service requests, verifying service status, transmitting service data and 
so forth as described more fiiUy below. 

15 La the exemplary embodiment of Fig. 1, several different system modalities 

are provided with remote service by the service facility. These and other modalities 
may be similarly serviced by the service facility, depending upon the capabilities of 
the service facility, the types of diagnostic systems subscribing to service contracts 
with the faciUty, as well as other factors. In general, however, the present technique 

20 is particularly well suited to providing remote service to a wide variety of medical 

diagnostic system modalities, including MRI systems, CT systems, ultrasound 
systems, positron emission tomography (PET) systems, nuclear medicine systems, 
and so forth. Moreover, the various modality systems serviced in accordance v^dth 
the present techniques may be of different type, manufacture, and model. Service 

25 requests and data transmitted between the systems and the service facility includes 

data for identifying the type and modality of the serviced system, as well as data 
specifically adapted to the system modality and model. It should also be noted that, 
as used herein, the term "service request" is intended to include a wide range of 
inquiries, comments, suggestions and other queries or messages generated by a 

30 diagnostic system or an institution in which a system is disposed or managed. In 

particular, such requests may relate to problems occurring on systems, applications 
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questions, questions of a general nature, questions relating to financial or 
subscription arrangements, information sharing, reports, applications, protocols, and 
so forth. 

5 Depending upon the modality of the systems, various subcomponents or 

subsystems will be included. Li the case of MRI system 14, such systems will 
generally include a scanner 26 for generating pulsed magnetic fields and for 
collecting signals firom emissions by gyromagnetic material within a subject of 
interest. The scanner is coupled to a control and signal detection circuit 28 which, in 

10 turn, is coupled to a system controller 30. System controller 30 includes a uniform 

platform for interactively exchanging service requests, messages and data with 
service faciUty 22 as described more fully below. System controller 30 is linked to a 
communications module 32, which may be included in a single or separate physical 
package from system controller 30. System controller 30 is also linked to an 

15 operator station 34 which will typically include a computer monitor 36, a keyboard 

38, as well as other input devices 40, such as a mouse. In a typical system, 
additional components may be included in system 14, such as a printer or 
photographic system for producing reconstructed images based upon data collected 
from scanner 14. Although reference is made herein generally to "scanners" in 

20 diagnostic systems, that term should be understood to include medical diagnostic 

data acquisition equipment generally, not limited to image data acquisition, as well 
as to picture archiving communications and retrieval systems, image management 
systems, facility or institution management systems, viewing systems and the like, 
in the field of medical diagnostics. More particularly, equipment benefiting from 

25 the present techniques may include imaging systems, clinical diagnostic systems, 

physiological monitoring systems and so forth. 

Similarly, CT system 16 will typically include a scanner 42 which detects 
portions of x-ray radiation directed through a subject of interest. Scanner 42 is 
30 coupled to a generator and controller, as well as to a signal acquisition unit, 

represented collectively at reference numeral 44, for controlling operation of an x- 
ray source and gantry within scanner 42, and for receiving signals produced by a 
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detector array moveable within the scanner. The circuitry within the controller and 
signal acquisition components is coupled to a system controller 46 which, like 
controller 30 mentioned above, includes circuitry for commanding operation of the 
scanner and for processing and reconstructing image data based upon the acquired 
signals. System controller 46 is linked to a communications module 48, generally 
similar to communications module 32 of MRI system 14, for transmitting and 
receiving data for remote service of system 16. Also, system controller 46 is 
coupled to an operator station 50 which includes a computer monitor 52, a keyboard 
54, as well as other input devices 56, such as a mouse. Moreover, like MRI system 
14, CT system 16 will generally include a printer or similar device for outputting 
reconstructed images based upon data collected by scanner 42. 

Other modality devices will include circuitry and hardware particularly 
configured for acquiring or producing signals in accordance with their particular 
design, hi particular, in the case of ultrasound system 18, such systems will 
generally include a scanner and data processing unit 58 for transmitting ultrasound 
signals into a subject of interest, and for acquiring resultant signals which are 
processed for reconstructing a useful image. The system includes a system 
controller 60 which regulates operation of scanner 58 and which processes acquired 
signals to reconstruct the image. Moreover, system 18 includes a commxmications 
module 62 for transmitting service requests, messages and data between system 
controller 60 and service facility 22. System 18 also includes an operators station 
64, including a monitor 66, as well as input devices such as a keyboard 68. 

Where more than one medical diagnostic system is provided in a single 
facility or location, as indicated in the case of MRI and CT systems 14 and 16 in 
Fig. 1, these may be coupled to a management station 70, such as in a radiology 
department of a hospital or clinic. The management station may be linked directly 
to controllers for the various diagnostic systems, such as controllers 30 and 46 in the 
illustrated embodiment. The management system may include a computer 
workstation or personal computer 72 coupled to the system controllers in an intranet 
configuration, in a file sharing configuration, a cHent/server arrangement, or in any 
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other suitable manner. Moreover, management station 70 will typically include a 
monitor 74 for viewing system operational parameters, analyzing system utilization, 
and exchanging service requests and data between the facility 20 and the service 
facility 22, Input devices, such as a standard computer keyboard 76 and mouse 78, 
5 may also be provided to facilitate the user interface. It should be noted that, 

alternatively, the management system, or other diagnostic system components, may 
be "stand-alone" or not coupled directly to a diagnostic system. In such cases, the 
service platform described herein, and some or all of the service functionality 
nevertheless be provided on the management system. Similarly, in certain 
10 apphcations, a diagnostic system may consist of a stand-alone or networked picture 

archiving communications and retrieval system or a viewing station provided with 
some or all of the functionality described herein. 

The communication modules mentioned above, as well as workstation 72 
15 and field service units 24 may be Unked to service facility 22 via a remote access 

network 80. For this purpose, any suitable network connection may be employed. 
Presently preferred network configurations include both proprietary or dedicated 
networks, as well as open networks, such as the Internet. Data may be exchanged 
between the diagnostic systems, field service units, and remote service facihty 22 in 
20 any suitable format, such as in accordance with the Intemet Protocol (IP), the 

Transmission Control Protocol (TCP), or other known protocols. Moreover, certain 
of the data may be transmitted or formatted via markup languages such as the 
HyperText Markup Language (HTML), or other standard languages. The presently 
preferred interface structures and communications components are described in 
25 greater detail below. 

Within service facility 22, messages, service requests and data are received 
by communication components as indicated generally at reference numeral 82. 
Components 82 transmit the service data to a service center processing system, 
30 represented generally at reference numeral 84 in Fig. 1. The processing system 

manages the receipt, handling and transmission of service data to and fi-om the 
service facility. In general, processing system 84 may include one or a plurality of 
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computers, as well as dedicated hardware or software servers for processing the 
various service requests and for receiving and transmitting the service data as 
described more fully below. Service facility 22 also includes a bank of operator 
workstations 86 which may be staffed by service engineers who address the service 
requests and provide off and on-line service to the diagnostic systems in response to 
the service requests. Also, processing system 84 may be linked to a system of 
databases or other processing systems 88 at or remote from the service facility 22. 
Such databases and processing systems may include extensive database information 
on operating parameters, service histories, and so forth, both for particular 
subscribing scanners, as well as for extended populations of diagnostic equipment. 
As described below, such databases may be employed both for servicing of 
particular diagnostic systems and for tracking such servicing, as well as for deriving 
comparison data for use in servicing a particular system or a family of systems. 

Fig. 2 is a block diagram illustrating the foregoing system components in a 
functional view. As shown in Fig. 2, the field service units 24 and the diagnostic 
systems 12 can be linked to the service facility 22 via a network connection as 
illustrated generally at reference numeral 80. Within each diagnostic system 12, a 
uniform service platform 90 is provided. Platform 90, which is described in greater 
detail below with particular reference to Fig, 3, includes hardware, firmware, and 
software components adapted for composing service requests, transmitting and 
receiving service data, establishing network connections and managing financial or 
subscriber arrangements between diagnostic systems and the service facility. 
Moreover, the platforms provide a uniform graphical user interface at each 
diagnostic system, which can be adapted to various system modalities to facilitate 
interaction of clinicians and radiologists with the various diagnostic systems for 
service functions. The platforms enable the scanner designer to interface directly 
with the control circuitry of the individual scanners, as well as with memory devices 
at the scanners, to access image, log and similar files needed for rendering requested 
or subscribed services. Where a management station 70 is provided, a similar 
uniform platform is preferably loaded on the management station to facilitate direct 
interfacing between the management station and the service facility. In addition to 
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the uniform service platform 90, each diagnostic system is preferably provided v^ith 
an alternative communications module 92, such as a facsimile transmission module 
for sending and receiving facsimile messages between the scanner and remote 
service facilities. 

5 

Messages and data transmitted between the diagnostic systems and the 
service facility traverse a security barrier or "firewall" contained within processing 
system 84 as discussed below, which prevents unauthorized access to the service 
facihty in a manner generally known in the art. A modem rack 96, including a series 
10 of modems 98, receives the incoming data, and transmits outgoing data through a 

router 100 which manages data traffic between the modems and the service center 
processing system 84. 

As mentioned above, processing system 84 receives and processes the 
15 service requests and data, and interfaces with additional service components, both at 

the service facility and remote fi-om the facihty. In the diagram of Fig. 2, operator 
workstations 86 are coupled to the processing system, as are remote databases or 
computers 88. In addition, at least one local service database 102 is provided for 
verifying license and contract arrangements, storing service record files, log files, 
20 and so forth. Moreover, one or more communication modules 104 are linked to 

processing system 84 to send and receive facsimile transmissions between the 
service facility and the diagnostic systems or field service units. 

Fig, 3 illustrates diagrammatically the various fimctional components 
25 comprising the uniform service platform 90 within each diagnostic system 12. As 

shovra in Fig. 3, the uniform platform includes a device connectivity module 106, as 
well as a network connectivity module 108. Network connectivity module 108 
accesses a main web page 110 which, as mentioned above, is preferably a markup 
language page, such as an HTML page displayed for the system user on a monitor at 
30 the diagnostic system. Main web page 110 is preferably accessible fi^om a normal 

operating page in which the user will configure examination requests, view the 
results of examinations, and so forth such as via an on-screen icon. Through main 
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web page 1 10, a series of additional web pages 112 are accessible. Such web pages 
permit service requests to be composed and transmitted to the remote service 
facihty, and facihtate the exchange of other messages, reports, software, protocols, 
and so forth as described more fiiUy below. It should be noted that as used herein 
the term "page" includes a user interface screen or similar arrangement which can be 
viewed by a user of the diagnostic system, such as screens providing graphical or 
textual representations of data, messages, reports and so forth. Moreover, such 
pages may be defined by a markup language or a programming language such as 
Java, perl, java script, or any other suitable language. 

Network connectivity module 108 is coupled to a license module 114 for 
verifying the status of license, fee or contractual subscriptions between the 
diagnostic system and the service facility. As used herein, the term "subscription" 
should be understood to include various arrangements, contractual, commercial or 
otherwise for the provision of services, information, software, and the like, both 
accompanies with or without payment of a fee. Moreover, the particular 
arrangements manages by systems as described below may include several different 
types of subscriptions, including time-expiring arrangements, one-time fee 
arrangements, and so-called "pay per use" arrangements, to mention but a few. 

License module 1 14 is, in turn, coupled to one or more adapter utilities 116 
for interfacing the browser, server, and communications components with modality 
interface tools 118. In a presently preferred configuration, several such interface 
tools are provided for exchanging data between the system scanner and the service 
platform. For example, modality interface tools 118 may include applets or servlets 
for building modality-specific applications, as well as configuration templates, 
graphical user interface customization code, and so forth. Adapters 116 may interact 
with such components, or directly with a modality controller 120 which is coupled 
to modality-specific subcomponents 122, The modahty controller 120 and 
modality-specific subcomponents 122 will typically include a preconfigured 
processor or computer for executing examinations, and memory circuitry for storing 
image data files, log files, error files, and so forth. Adapter 116 may interface with 
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such circuitry to convert the stored data to and from desired protocols, such as 
between the HyperText Transfer Protocol (HTTP) and DICOM, a medical imaging 
standard for data presentation. Moreover, transfer of files and data as described 
below may be performed via any suitable protocol, such as a file transfer protocol 
(FTP) or other network protocol. 

hi the illustrated embodiment, device connectivity module 106 includes 
several components for providing data exchange between the diagnostic system and 
the remote service facility. Li particular, a connectivity service module 124 provides 
for interfacing with network connectivity module 108. A Point-to-Point Protocol 
(PPP) module 126 is also provided for transmitting hitemet Protocol (IP) packets 
over remote communication connections. Finally, a modem 128 is provided for 
receiving and transmitting data between the diagnostic system and the remote 
service facility. As will be appreciated by those skilled in the art, various other 
network protocols and components may be employed within device connectivity 
module 106 for facilitating such data exchange. 

Network connectivity module 108 preferably includes a server 130 and a 
browser 132. Server 130 facilitates data exchange between the diagnostic system 
and the service facility, and permits a series of web pages 110 and 1 12 to be viewed 
via browser 132. Li a presently preferred embodiment, server 130 and browser 132 
support HTTP applications and the browser supports Java appHcations. Other 
servers and browsers, or similar software packages may, of course, be employed for 
exchanging data, service requests, messages, and software between the diagnostic 
system, the operator and the remote service facility. Finally, a direct network 
connection 134 may be provided between server 130 and an operator workstation, 
such as management station 70 within the medical facility (see Figs. 1 and 2). 

In a present embodiment, the components comprising network connectivity 
module may be configured via an application stored as part of the uniform platform. 
In particular, a Java apphcation licensed to a service engineer enables the engineer to 
configure the device connectivity at the diagnostic system to permit it to connect 
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with the service facihty. Features of the application are segmented into separate 
tabbed pages accessible by the service engineer. The application is entered via a 
hcense agreement screen. Once accepted, the service engineer can configure 
parameters of the system modem, the schedule for running automatic diagnostic 
5 checks, and establish electronic messaging, such as for automatic service report 

generation. Once the modem is configured, the service engineer establishes contact 
with the service facility and provides data enabling the service facility to download 
any remaining data needed for secure communication between the system and the 
service center. Upon exit from the application, a configuration status is presented to 
10 the service engineer, including status of an automatic test of connectivity between 

the sites. 

Fig. 4 illustrates exemplary fimctional components for service facility 22. 
As indicated above, service facihty 22 includes a modem rack 96 comprising a 

15 plurality of modems 98 coupled to a router 100 for coordinating data 

communications with the service facility. An HTTP service server 94 receives and 
directs incoming and outgoing transactions with the facility. Server 94 is coupled to 
the other components of the facility through a firewall 138 for system security. 
Operator workstations 86 are coupled to the port manager for handling service 

20 requests and transmitting messages and reports in response to such requests. An 

automated service unit 136 may also be included in the service facility for 
automatically responding to certain service requests, sweeping subscribing 
diagnostic systems for operational parameter data, and so forth, as described below, 
hi a presently preferred embodiment, the automated service unit may operate 

25 independently of or in conjunction with the interactive service components 

comprising processing system 84. It should be noted that other network or 
communications schemes may be provided for enabling the service facihty to 
communicate and exchange data and messages with diagnostic systems and remote 
service units, such as systems including outside Internet service providers (ISP's), 

30 virtual private networks (VPN's) and so forth. 



15 



GEMS:0029 
15-SV-4769 



Behind firewall 138, an HTTP application server 140 coordinates handling 
of service requests, messaging, reporting, software transfers and so forth. Other 
servers may be coupled to HTTP server 140, such as service analysis servers 142 
configured to address specific types of service requests, as described more fully 
below. In the illustrated embodiment, processing system 84 also includes a license 
server 144 which is coupled to a Ucense database 146 for storing, updating and 
verifying the status of diagnostic system service subscriptions. Altematively, where 
desired, license server 144 may be placed outside of fire wall 138 to verify 
subscription status prior to admission to the service facility. 

Handling of service requests, messaging, and reporting is ftirther coordinated 
by a scheduler module 148 coupled to HTTP server 140. Scheduler module 148 
coordinates activities of other servers comprising the processing system, such as a 
report server 150, a message server 152, and a software dovraload server 154. As 
will be appreciated by those skilled in the art, servers 150, 152 and 154 are coupled 
to memory devices (not shown) for storing data such as addresses, log files, message 
and report files, applications software, and so forth. In particular, as illustrated in 
Fig. 4, software server 154 is coupled via one or more data channels to a storage 
device 156 for containing transmittable software packages which may be sent 
directly to the diagnostic systems, accessed by the diagnostic systems, or suppHed 
on pay-per-use or purchase basis. Message and report servers 152 and 154 are 
ftirther coupled, along with communications module 104, to a delivery handling 
module 158, which is configured to receive outgoing messages, insure proper 
connectivity with diagnostic systems, and coordinate transmission of the messages. 

The foregoing components may, of course, include finther subcomponents 
for executing specific fiinctions in the processing system. Figs. 4A and 4B illustrate 
such subcomponents for license server 144 and report server 150. As shown in Fig. 
4A, Ucense server 144 includes a vahdity check module 160 linked to Hcense 
database 146. The hcense database is ftirther linked to a key information module 
162, a contract population process module 164, and a site population process 
module 166. The latter module is ftirther coupled to systemic information databases 
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168. As described more fully below, validity check module 160 receives site 
information, verifies site and license information with hcense database 146, and 
accesses resulting status information from the database. Module 160 then may 
output the site status and license status information to the HTTP server within the 
5 processing system for enabling consideration and response to a service request or for 

otherwise addressing the service request. Module 162 receives key information and 
site information regarding the particular diagnostic system requesting service, and 
transmits site identification, configuration, and similar information to other system 
components through the intermediary of database 146. Similarly, population 
10 process modules 164 and 166 store and provide general contract status data, service 

security keys, site demographic information, and so forth. 

The functional components of report server 150, as shown in Fig. 4B, may 
include a report generation module 170, coupled to a report access module 172, a 

15 report storage device 174, and an automated data gathering module 176. Automated 

data gathering module 176 may include all or a portion of an automated service unit 
136 as shown in Fig, 4. As described more fully below, the components of the 
report server receive scanner data, service information, warehouse information, and 
the like, and generate system-specific reports based upon this and collected 

20 information, such as from gathering module 176. Such reports may also include 

information on entire populations of similar diagnostic systems, such as for 
comparison purposes, component hfe predictions and so forth. The reports may be 
stored and accessed remotely by the diagnostic system as described below, 

25 Fig, 5 illustrates certain of the functional components contained within an 

exemplary field service unit 24. Field service unit 24 may include a portable 
computer designed for use by remote service engineers. The unit includes a service 
platform which includes certain functional circuitry for estabUshing a uniform 
service base as discussed above for the diagnostic systems themselves. Moreover, 

JO the service units include specific service tools which enable the field engineer to 

request and receive remote service messages, reports on specific diagnostic systems, 
service schedules, and so forth. Through the service platform, therefore, the field 
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engineer may access system configurations, historic log information, system 
network information, analysis logs and data, and so forth. In addition, the field 
service unit described below, in conjunction with the system platform and the 
service facility components, permits such information to be accessed either by the 
field engineer on the field service unit, or at the diagnostic system itself (e.g. when 
the service engineer is on-site), or from the remote service facility. The field 
engineer may also update service records either from the field service xmit or from 
the diagnostic system, as desired. 

Thus, as shown in Fig. 5, an exemplary field service unit includes a device 
connectivity module 106 and a network connectivity module 108. Device 
connectivity module 106 may include connectivity interface circuitry 124, a network 
or PPP module 126, and a modem 128, as described above for the diagnostic system 
with reference to Fig. 3. The network connectivity module 108 may, in turn, include 
a server 130 and browser 132 substantially identical to those of the diagnostic 
systems, enabling the field engineer to receive, view and compose messages, reports, 
and so forth via a main web page 110 and a series of web pages 112, Moreover, an 
access module 114A is provided for allowing the service facility to verify the 
Ucense and security status of the field service xmit. For example, the access module, 
in cooperation with circuitry at the service facility, may permit a field service 
engineer to access data or applications providing some or all of the flmctionality 
offered to service engineers at the service facility. Such fimctionalities may be 
similar to those provided at the diagnostic systems themselves, or may offer the 
service engineer a wider range of service options. One or more adapter modules 116 
provide for interfacing the network circuitry with various field service tools. In 
particular, the field service unit may be equipped witii service applications, as 
indicated at blocks 180, such as for analyzing diagnostic system performance data, 
scheduling regular or special service calls, scheduling for shipment of replacement 
parts, and so forth. Other service appUcations may include applications generally 
similar to those executed on the operator workstations 86 of the service facility (see, 
e.g. Fig. 4), Such appUcations may permit the field service engineer to address 
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service requests at the diagnostic system site, or remote from the site as required, 
and transmit service messages and updates via the remote field service unit. 

In a presently preferred embodiment, the foregoing functional circuitry may 
5 be configured as hardware, firmware, or software on any appropriate computer 

platform. For example, the fimctional circuitry of the diagnostic systems may be 
programmed as appropriate code in a personnel computer or workstation either 
incorporated entirely in or added to the system scanner. The fimctional circuitry of 
the service facility may include additional personal computers or workstations, in 

10 addition to a main frame computer in which one or more of the servers, the 

scheduler, and so forth, are configured. Finally, the field service units may comprise 
personal computers or laptop computers of any suitable processor platform. It 
should also be noted that the foregoing fimctional circuitry may be adapted in a 
variety of manners for executing the fimctions described herein. In general, the 

15 fimctional circuitry facilitates the exchange of service data between the diagnostic 

systems and a remote service facility, which is preferably implemented in an 
interactive maimer to provide regular updates to the diagnostic systems of service 
activities. 

20 As described above, both the diagnostic systems and the field service units 

preferably facilitate interfacing between a variety of diagnostic system modalities 
and the remote service facility via a series of interactive user-viewable pages. Figs. 
6 through 11 illustrate exemplary pages for providing interactive information, 
composing service requests, selecting and transferring messages, reports and 

25 diagnostic system sofiware, and so forth. It should be noted that through the 

following discussion, reference is made to viewable pages for interfacing in the 
language of the present description. However, in a presently preferred embodiment, 
the platform may be configured to present such interface pages in several different 
languages, depending upon the country in which the system is installed. As 

30 illustrated first in Fig. 6, a main web page 1 10 is accessible from a normal diagnostic 

system screen viewable on the diagnostic system monitor 36, 52 or 66. Main web 
page 110 may therefore be viewable by clicking an input device such as a mouse on 
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an icon (not shown) on the normal operational screen. Main web page 110 includes 
a series of navigation devices 178 in the form of graphical buttons for accessing 
other interface pages in the graphical user interface. In the illustrated embodiment, 
these graphical devices include a service request button 180 for accessing a service 
request page, an appUcations button 182 for accessing an apphcations page, a system 
reports button 184 for accessing service reports, and a messages button 186 for 
sending and receiving interactive service messages. A help button 187 is provided 
for accessing user information, help topics and so forth, which may be resident on 
the system, or available through on-line sources viewable through the system 
browser, A close or exit button 188 is provided for returning to the normal scanner 
interface page. In addition to these navigational devices, main page 110 includes a 
message area 190 in which information regarding the most recent messages is 
displayed. This information may include identification of the time and date 
received, the originator of the message, and a brief summary of the message content 
or title. Thus, upon accessing main page 110, the system user is made aware of 
service activities carried out by the remote service facility or field service engineer. 

Fig. 7 illustrates the applications page 192 accessed by actuation of the 
appUcations button 1 82 in the main page. As in the main page, the applications page 
includes a series of graphical buttons 178 for navigating through the other pages of 
the graphical user interface, including a main screen button 194 for returning to the 
main screen shown in Fig. 6. Moreover, additional web pages may be accessible 
through the applications page, such as a documentation or a help page or series of 
pages, accessible through a graphical button 196. A protocols page is accessible 
through a graphical button 198. Moreover, page 192 is provided with a text area 
200 in which text describing various service documentation, messages, modality 
equipment, operational instructions, and so forth may be displayed. 

It should be noted that in a presently preferred configuration, the information 
displayed within text area 200 is specifically designed for the particular modality 
and type of diagnostic system on which the uniform platform is installed. Thus, as 
described below, when the service center is placed into network contact with the 
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diagnostic system, the identification of the diagnostic system to the service center 
allows the service center to transmit and display modality-specific information in the 
text area. In the embodiment illustrated in Fig. 7, such text includes documentation 
on imaging protocol or examination descriptions, a system nev^sletter specifically 
adapted for the modality and system type, updated questions and answers, and 
instructional suggestions for operation of the diagnostic system. The user can access 
the specific documents described in the text area by selection of all or a portion of 
the text describing the documents. In the presently preferred embodiment, the 
accessed documents may be stored in local memory devices within the diagnostic 
system, or selection of the text may result in loading of a imiform resource locator 
(URL) for accessing a remote computer or server via a network link. 

As mentioned above, the uniform graphical user interface facilitates 
formulation of service requests and enables system designers to permit such service 
requests in a similar manner across several diagnostic system modalities. Fig. 8 
illustrates an exemplary interface page for formulating such service requests. In the 
page shown in Fig. 8, a "snap shot" or current system state may be captured as the 
basis for the service request. The service request page would be accessed from the 
normal operating page at the scanner, through the service request button 180 in the 
main web page or one of the other web pages. With the system state remaining at its 
condition just prior to accessing the service request page, image data files, log files, 
error files, and so forth may be identified, captured, stored and transmitted to the 
service facility for evaluation of potential problems in the diagnostic system. As 
will be appreciated by those skilled in the art, the service request therefore enables 
the user to identify potential imaging system difficulties that may not be apparent in 
subsequent examinations, or may not reoccur on a predictable basis. It should be 
noted that the service requests formulated via a page such as that shown m Fig. 8 
and described below are not limited to identifying image acquisition or processing 
problems, or to capturing image files only. Such requests may relate to general or 
system-specific questions, or may identify data files containing system configuration 
data, and data indicative of historical operational parameters or events. Such events 
may include parameter limits exceeded, timeouts, protocol configurations, hardware 
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and software configurations, work queues, and so forth. Similarly, image data 
identified for evaluation may include both processed, partially processed and raw 
data from which images are subsequently reconstructed. 

5 The service request page 202, as shown in Fig. 8, includes graphical buttons 

204 which permit the user to identify whether the service request is urgent or 
whether the request entails simply an apphcations question or non-urgent inquiry. 
Li the illustrated embodiment, a series of interactive selections 206 are available, 
permitting the user to identify, if possible, the type of problem which may be 

10 occurring. Furthermore, a series of identification areas 208 allow the user to insert 

text to identify both the user, the user's location or telephone number, and other 
contact information. It should be noted that the server included in the uniform 
platform aheady includes unique system identification data which supplements the 
information input by the user. Such information may be input by a user, or may be 

15 supplied automatically by the system. Where the service request involves a specific 

image or examination sequence, the user may input such identifying data in a series 
of examination identification areas 210. Where the examination request involves an 
examination which has just been attempted or is underway, the data required in areas 
210 may be transmitted directly from the modality controller. A further area 212 

20 permits the user to identify or describe the type of service problem being 

experienced. A date stamp area 214 provides an identification of the date and time 
of the serviceable problem or question, hi appropriate situations, a default time 
drawn from a system clock may be provided in this area, or the default time may be 
overridden by the user. Finally, in the embodiment illustrated in Fig. 8, the user 

25 may complete and submit the service request by selecting a graphical send button 

216. It should also be noted that in the illustrated embodiment, a graphical service 
center telephone directory button 218 is provided, by which the user may access 
numbers for immediately contacting the remote service facility. 

30 Fig. 9 illustrates a further interface page for informing the system operator of 

the current and past state of service activities, and for transmitting reports to the 
diagnostic system from the remote service facility. The system reports page 218 
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includes a series of graphical buttons 178, including certain options which may be 
provided across a number of modalities, such as a service history button. When the 
service history button is selected, text appears in a text area 222 which identifies the 
type of service performed on the diagnostic system, either locally by a service 
5 engineer or remotely by the remote service facility. The text may also indicate the 

nature of the organization performing the service, appUcable reference numbers, and 
the date on which the service was performed. The diagnostic system operator is 
thereby apprised of all service activities provided to the diagnostic system, and 
maintains and up-to-date, comprehensive list of the service activities. 

10 

Other selections available in the system reports page may include system 
usage, accessible through a graphical button 224, and monitoring activities 
accessible through a button 226. It should be noted that the specific information 
accessed through selection of one of the graphical buttons will be adapted not only 

15 for the modality and system type, but for the specific system in which the user 

interface is installed. Thus, under a system usage page (not shown) a CT system 
may include data indicative of the performance of an x-ray radiation source, while in 
an MRI system, the same graphical button may access information on cryogen levels 
and temperatures. It should also be noted that specific modahty or system buttons 

20 may be provided, such as a tube usage button 228 in Fig. 9, suitable for x-ray and 

CT systems. Although such additional interface access devices are configured in 
individual systems, they are preferably provided in a uniform location and lay out 
which can be easily learned and used by operations personnel 

25 Fig. 10 illustrates a messages page for the imiform platform and graphical 

user interface. Messages page 230 is accessible through the main page shown in 
Fig. 6. Upon accessing the messages page, the system user is provided with 
information on service and other messages received by the diagnostic system via a 
network connection. A pair of graphical buttons are provided for selecting either 

30 current messages or saved messages received by the system. Upon selection of 

either the current or saved messages button, the user is provided with a hst of 
messages in a text area 232, identifying the subject of the message, the originator. 
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and the date received. The body of the message, and graphical symbols indicating 
possible attachments (none shown) are also provided in the text area 232. The user 
may select a particular message for viewing by selection of the entire or a portion of 
the text defined in the tabulated message Ust. 

5 

As described more fully below, when a service request is composed and 
transmitted to the remote service center, an acknowledgment message is generated 
and returned to the diagnostic system, indicating that the service request has been 
received and is being processed. Moreover, where reports are generated, based 
10 either on a service request or on an automatic or a periodic basis, the availabihty of 

such reports may be flagged through the message page. Both the message and the 
report may then be accessed by appropriate selection of the message title in the 
tabulated Ust. The user may save or delete each message by selection of an 
appropriate save or delete graphical button 234. 

15 

As illustrated in Fig. 11, further interface pages may be provided for hsting 
available software, uploading such software into the particular modality controller, 
or downloading the software from a library or service facility. In the embodiment 
illustrated in Fig. 11, such software includes a series of examination or imaging 

20 protocols. As will be appreciated by those skilled in the art, such protocols define 

configuration parameters for specific examination sequences. In general, however, 
as used herein, the term "protocols" generally refers to instructions or parameters for 
acquiring, manipulating, displaying, archiving or managing medical diagnostic data. 
The protocols are specifically adapted for the modality of the diagnostic system, and 

25 may be further adapted for specific system types and capabilities. In presently 

preferred configurations, the protocols may be stored locally at the particular 
diagnostic system, or may be available at the diagnostic system via a variety of 
transfer options or memory support devices, such as CD ROM storage discs. It 
should be noted, however, that interface pages such as that shown in Fig. 1 1, and the 

30 processing described below, are not limited to transfer of protocols, but may include 

transfer of a wide range of programs. 
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The available software routines are listed and described briefly in the user- 
viewable page. In Fig. 11, the protocol screen 236 lists a series of imaging protocols 
within a text area 238. For each protocol provided in the Usting, a brief description 
of the protocol and its configuration parameters is provided as indicated at reference 
numeral 240, as is a condensed image or thumbnail sketch of the type of image 
available through application of the protocol, as indicated at reference nimieral 242. 
Additional protocols may be made available by paging down the list in a 
conventional manner. Also, in a preferred embodiment, protocols presented in a 
menu may be sorted, such as by anatomy, imaging or acquisition technique, 
physiological condition or pathology, and so forth. As described in greater detail 
below, in a preferred embodiment, not only are the protocols displayed for reference 
purposes at the diagnostic system, but new or additional protocols may be added to 
the listing firom time to time, such as by downloading fi-om the service facility. 
Moreover, certain of the protocols may be made available on a fee-per-use, one-time 
payment, or a license basis. Furthermore, the user may upload examination 
configurations by selecting the thumbnail image or text associated with a particular 
protocol. Thus, the uniform user interface and platform facilitate not only viewing 
and hsting such routines and protocols, but assist in the examination configurations 
themselves. 

Figs. 12 through 16 illustrate exemplary control logic implemented by the 
functional components described above at the diagnostic systems, the service 
facility, and remote field service units. In particular, Fig. 12 illustrates exemplary 
logic for composing and transmitting a service request via the graphical user 
interface and uniform platform. The control logic, indicated generally by reference 
numeral 250, begins at step 252 wherein a service page is accessed fi-om a normal 
operating page at the diagnostic system or at a management station. The logical 
steps illustrated in Fig. 12 are particul^ly adapted for composing service requests 
based on specific instances of malfunctions or specific questions on examination 
sequences. Thus, at step 252 a service request page such as that shown in Fig. 8 is 
accessed. At step 254 the diagnostic system may verify a subscriber status required 
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for the requested service. In particular, the various service requests may be 
categorized by type, and associated with specific contract types, subscriber services, 
hcenses, and so forth. Such subscriber data v^ill be stored in a hcense module such 
as module 1 14 shown in Fig. 3. Where the service requests are freely made by the 
scanner, this step may be eliminated. However, where specific service subscriptions 
are required, a comparison is made at step 254 between the required contractual 
arrangement or subscriber hcense and the similar information on file for the 
diagnostic system. At step 256 in Fig. 12, the diagnostic system connectivity 
module dials and connects the diagnostic system to the service facihty. At step 258 
the service request is composed, such as by selecting or inputting the question 
description, user identification, problem description and other information as 
described above with respect to Fig. 8. 

At step 260, the diagnostic system server 130 (see Fig. 3) determines the 
type and location of data that may be required for addressing the service request. 
For example, for service requests regarding imaging sequences, acquired image data 
files may be identified, along with scanner log files, error files, and so forth. More 
particularly, the data identified (and later transmitted if required) may include both 
raw or processed image data, software configuration information, systems data (e.g. 
hardware and software identification and configuration), and so forth. Certain of the 
data may be specific to the modality of the system (such as data in a DICOM 
format), and may be defined by modahty through adaptation of the uniform platform 
via the modality interface components. Where such data is required for properly 
addressing the service request, the data files are located as indicated at step 262. The 
files may be backed up or stored from the modahty-specific circuitry through the 
intermediary of adapter modules, such as adapter module 116 (see Fig, 3). These 
steps in the exemplary logic therefore permit the user to configure a service request 
which effectively captures a state of the diagnostic system which gave rise to the 
service request. The request may be thereby linked to the specific problem for 
which service is needed. 
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At step 264 a message is formatted based upon the service request. The 
message formatting will typically include identification of the diagnostic system, a 
facility in which the system is located, and so forth. It should be noted that in the 
preferred embodiment, the service request and the message is stripped of 
information relating to specific patient identifications. Other data, such as financial 
or account information may be included with the message or may similarly be 
stripped fi*om the request. Where the requested service is permitted by the subscriber 
arrangement, the logic proceeds to step 266 where the request is placed in a message 
queue at the diagnostic system. If the subscription arrangement does not permit the 
specific type of request, the logic may produce a message notifying the system user 
of this fact, may proceed based upon an exception to the subscriber arrangements, or 
both. 

At step 268 the service request message is transmitted. The service facility 
receives the service request and processes the request as summarized below. In the 
preferred embodiment a request acknowledgment signal is immediately transmitted 
by the service facihty back to the diagnostic system and is received by the diagnostic 
system at step 270. The diagnostic system operator is thereby immediately provided 
with feedback on the status of the service request, including information relating to a 
reference code and estimated handling time. At step 272 a portion or all of the data 
files may be transmitted by the diagnostic system to the service facility. 
Alternatively, transmission of all or some of the data files may be delayed until a 
subsequent service connection session. At step 274, the acknowledgment message 
is posted on the message page of the graphical user interface, and a notification that 
the message has been received may be posted on the interface page which is 
currently being viewed at the diagnostic system. At step 276 the diagnostic system 
may disconnect from the service facility. Altematively, additional messages, service 
requests, and so forth may be transmitted, or other remote activities may be 
performed at this stage. When certain of the data required to address the service 
request is not transmitted immediately, the service facility may recontact the medical 
diagnostic system at a subsequent time. As indicated at step 278, a data file pull 
request may be transmitted by the service facility, and, in response to the request, the 
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platform at the diagnostic system will access the required files and transmit the data 
to the service facility for analysis. 

Fig. 13 illustrates steps in exemplary control logic for addressing the service 
request at the remote service facility. This request handling logic, indicated 
generally by reference numeral 280, begins with receipt of the request as indicated at 
step 282, The request is received via the network connectivity modules of the 
service facility and is handled by the service center processing system including the 
HTTP server 140 and the analysis server 142 (see Fig. 4). In addition to the steps 
illustrated in Fig. 13, the service facility servers will verify license or other 
subscriber data for the diagnostic system or site requesting the service as described 
more fully below with reference to Fig. 14. 

Upon receipt of the service request and subscriber clearance, the service 
facihty processing system determines, at step 284, whether a service dispatch has 
been opened. As used herein, the term "dispatch" refers generally to a service 
request tracking or handling technique, such as for referencing a service request or 
identifying the service request or response at a later time. The logical steps executed 
at step 284 may include comparison of the origin and nature of the service request 
with service requests aheady received and being handled by the service facility. If, 
through this comparison, it is determined that no dispatch has been opened for the 
particular request, a dispatch is created at step 286 and the service request is placed 
in a handling queue. If a dispatch has already been created, it is determined at step 
288 whether the dispatch has been assigned to a service facihty engineer for 
handhng. If the dispatch has not yet been assigned, a note is appended to the 
dispatch at step 290 indicating that the service request has been repeated. From 
either step 284 or step 290, a message is generated at step 292 including the 
reference number of the dispatch in the service facility or an update on the status of 
the preexisting dispatch. This message is then transmitted to the requesting 
diagnostic system or site and is received and posted by the site as described above 
with respect to Fig. 12. 
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Following transmission of the acknowledgment message at step 292, a 
modality service engineer is notified of the service request at step 294. Because in 
the present technique the service facility may provide interactive service to a variety 
of system modalities, at step 294 a service engineer, typically staffing a workstation 
86 (see Fig. 4) in the service facility is assigned service requests according to the 
particular modality of the diagnostic system. It should be noted, however, that the 
modality service engineer assigned the service request may be remote fi-om the 
service facility, and may be a field service engineer accessible through a field 
service unit 24 (see Figs, 1 and 2). At this point in the control logic, the service 
facility may be disconnected firom the requesting diagnostic system. 

Where the service request requires data, such as image data files, log files, 
and so forth, fi*om the diagnostic system, this data may be transmitted along with the 
request. However, where voluminous files are needed, or where files are identified 
by the service facility or by a service engineer subsequent to receipt of the request, 
the diagnostic system may be recontacted by the service facility as indicated at step 
296 to locate and transmit the needed data. At step 298 the data is accessed, 
transmitted and stored. The steps involved in recontacting the medical diagnostic 
system and transmitting the needed data files may require prompting of operations 
personnel for the input of specific information, or may be essentially transparent to 
the diagnostic systems operations personnel. Thus, the service facility server or 
servers may contact the diagnostic system server directly to access and transmit the 
needed data without intervention from the operations personnel at the diagnostic 
system facility. 

Depending upon the nature of the service request, tiie service facility 
engineer will perform analysis of the service issues and recontact the diagnostic 
system either in person, by telephone, or directly through the network connection 
and user interface. For particular service requests, the service facihty database may 
be utilized as indicated at step 300 in Fig. 13. Such databases will be called into 
play in reviewing or updating service history for the particular diagnostic system or 
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site, as well as for referring to configuration parameters, operating parameters, 
reference values, and so forth for the particular modality and system type. The 
databases accessed at step 300 may also include information relating to populations 
of diagnostic systems. Such information may be used by the service facility for 
comparison purposes, predicting possible future service needs, predicting 
component failure or degradation, and so forth. Moreover, the access to the 
databases at step 300 may include access to new or updated routines, protocols, 
instructional documentation and courses, schedules for training, and so forth. Where 
such information is located for the diagnostic system modality and type, the data 
may be included in messages formulated by the service facility and retransmitted to 
the diagnostic system. At step 302 the database information is therefore accessed, 
transmitted and stored for responding to the service request. 

Returning to step 288, if at this step it is determined that a dispatch has been 
assigned, a further dispatch may be created at step 304. A message, including the 
update regarding the dispatch, is formulated and sent at step 306 to inform the 
diagnostic system operations personnel of the status of the service request. A "pop 
up" box message is then addressed to the assigned service engineer at step 308, At 
step 310 the processing system determines whether the assigned engineer has 
accepted the dispatch. If no engineer accepts the dispatch or a predetermined 
interval lapses following display of the notification at step 308, the logic proceeds to 
step 294 wherein a modality service engineer is notified of the service request. 
Subsequent logic follows step 294 as described above. If upon displaying the notice 
at step 308 a particular service engineer accepts the service request, the request is 
assigned to the engineer at step 312 and the logic may proceed to step 296 as 
described above. 

In general, substantive responses to service requests will vary depending 
upon the tenor of the request. For example, the response may include suggestions 
for operating the diagnostic system or a medical institution in which the system is 
installed. Such information may provide "best practices'' type information for the 
particular system type or modality, as well as instructional information on user or 
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care for the system. The information may also include alerts, such as for anticipated 
service needs, scheduled or available training sessions and so forth. As described 
belov^, the response may further include programs or protocols or reports of system 
operation. It should be noted that the same type of information may be provided to 
the diagnostic system at the initiation of a remote service facility as part of a service 
program or otherwise. 

Fig. 14 illustrates steps in exemplary control logic executed by the service 
system for requesting, compiling and transmitting reports relating to service 
activities and operation of the medical diagnostic systems. The control logic, 
indicated generally by reference numeral 310, may begin in one of several manners, 
depending upon whether the report is being generated automatically, or upon request 
by a particular diagnostic system, or by a field engineer. Where the report is 
specifically requested by a diagnostic system, the report request is produced at step 
312 by the system operator or manager via the uniform graphical user interface 
described above. Various types of reports may be produced, including reports 
relating to recent or historical service activities, reports of the state of the diagnostic 
system, including numbers and types of examinations performed, errors or problems 
encountered, anticipated service needs, and so forth. For example, in x-ray and CT 
modalities, reports may relate to the operational status of the x-ray tubes, while in 
MRI systems, reports may include data relating to cryogen levels and temperatures. 
Moreover, reports may be requested for financial, subscription, or other management 
fimctions, including Ustings of current hcense subscriptions, accumulated fees for 
specific accounts (e.g. resulting fi-om pay-per-use or one-time fee arrangements), 
and so forth. Similar reports may be requested by field service engineers and 
technicians as indicated at step 314. 

At step 316 the report request is transmitted to the service facility. The 
report request will typically be transmitted in the form of a service request message 
as described above with reference to Fig. 12. At step 318 the transmitted request is 
acknov^ledged by a return acknowledgment message from the service facility, 
providing an indication of receipt and confirmation of handling of the report. 
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Certain of the reports available through the system may be provided free of 
charge, or based upon specific subscription types, or for a fee. Thus, as shown in 
Fig, 14 at step 320, following acknowledgment of receipt of the report request, the 
5 service facility processing system may evaluate the request to determine whether a 

fee is applicable. If a fee is associated with the report requested by the diagnostic 
system user, a fee/subscription routine is performed as indicated at step 322, 
Exemplary control logic involved in the fee/subscription routine is described below 
with reference to Fig. 15. 

10 

Following either step 320 or step 322, the service facility is contacted via a 
network connection as indicated at step 324, It should be noted that while the fee 
; verification steps indicated at steps 320 and 322 may be performed in the medical 

: diagnostic system, similar steps may be performed in the service facility following 

;15 step 324, or between the diagnostic system and the service facility interactively, 

, depending upon the particular fee arrangement and the data required for 

authorization of the fee structure. As indicated above, the reports generated by the 
^ service system may result from triggering events other than a specific request. In 

- particular, certain reports may be generated on a periodic basis, such as weekly or 

;20 monthly, and the service facility or the medical diagnostic system may generate a 

prompt for a report based upon a preestablished calendar or routine. Thus, as 
indicated at step 326, a periodic trigger may give rise to either the medical 
diagnostic system contacting the service facihty, or vice-versa. 

25 Once the diagnostic system and service facility are linked, the service facility 

may sweep the diagnostic system for data required for the desired report as indicated 
at step 328, As used herein, the term "sweep" refers generally to a process of 
connecting system components, such as via a network connection, identifying 
desired data, and transmitting the data, either in an "upload" or a "download" 

30 scenario, depending upon the nature of the data and its use in servicing a system. 

Such sweeps may occur on regularly scheduled bases, at desired times (e.g., at off- 
peak utilization times) or on demand by a system user or a system appUcation. The 
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system data may be stored in specific data files which are accessed either through 
intervention of a service engineer, or automatically by the service facility processing 
system. Once the data is accessed, it is transmitted to the service facility as 
indicated at step 330. At step 332 the service data records for the particular 
5 diagnostic system, as vv^ell as records kept for specific populations of similar 

diagnostic systems is updated as indicated at step 332, Subsequently, the service 
facihty may disconnect from the diagnostic system as indicated at step 334. In 
situations in vv^hich no fiulher data from the diagnostic system is needed for 
generation of the requested report, the steps of data collection and transmission may 
10 be eliminated. Moreover, the service facility may perform periodic data sweeps of 

subscribing systems without immediately generating a report through the subsequent 
logical steps. 

Where a report is to be generated based upon the acquired and historical 
15 data, the data is processed as indicated at step 336. As will be appreciated by those 

skilled in the art, the specific processing performed at this step may vary widely 
depending upon the nature of the diagnostic system, the data being processed, the 
type of report being generated, and so forth. For example, the data processing may 
include statistical analysis of the acquired data, categorization of data, as well as 
20 failure prediction analyses based upon the data, and so forth. The processed data is 

then compiled into the desired report as indicated at step 338. The report may 
include tabulated presentations, but may also include compilations of data into 
graphical formats, such as charts, graphs, and so forth, which may be accessible 
through a series of interactive pages viewable by the diagnostic system user via the 
25 local browser. 

At step 340 connection is reestabhshed with the diagnostic system and a 
notification of the availability of the report is transmitted. Several scenarios are 
available for transmission of the requested reports. As indicated at step 340, the 
30 requested report may be transmitted with the notification message in a "push" 

scenario, hi general, such techniques will append the report to a notification 
message which is transmitted and displayed at the diagnostic system. The user may 



33 



GEMS:0029 
15-SV-4769 



then access the report by appropriately selecting the message or an icon or text 
associated with the message. Where desired, however, reports may be compiled and 
a notification message provided at step 340, requiring the diagnostic system or the 
site to recontact the service facility and to "pull" the report as indicated at step 342. 
Where the report was requested by a field service engineer, similar steps are 
performed for transmitting the desired report to the field service engineer, or for 
permitting the field service engineer to pull the report based on a notification 
message. Moreover, where reports are requested by or transmitted to specific 
diagnostic systems or sites, the field service engineer may be notified of the request 
or the report at the same time as the report is transmitted to the diagnostic system. It 
should be noted that, when desired, a report maybe stored at a location remote from 
the diagnostic system, and nevertheless be viewed at the diagnostic system, such as 
via a browser interface (e.g. as a series of web pages). Moreover, where desired, a 
report may be requested by the system to be delivered via facsimile. In such cases, 
the report is requested and compiled as described above, then transmitted via 
facsimile to the institution in which the system is installed or, in appropriate 
appUcations, directly to the requesting system. 

Fig. 15 illustrates exemplary control logic for verifying and controlling 
fmancial and management arrangements between the service facility and diagnostic 
systems. As mentioned above, the logic illustrated in Fig. 15, designated generally 
by the reference numeral 350, may be triggered in a variety of manners. For 
example, verification of license or subscriber status may be triggered each time the 
service appHcation is accessed at the medical diagnostic system. Similar triggering 
may occur upon request for specific types of service at the remote service facility. 
Moreover, both the diagnostic system and the remote service facihty may include 
routines designed to trigger an alert upon expiration or anticipated expiration of a 
dated subscription. Furthermore, subscription or license verifications may relate to 
all or a part of the platform or configuration of the diagnostic system, such as 
particular programs, apphcations, protocols and so forth. In a presently preferred 
embodiment, other security checks may be performed in addition to such 
subscription verifications to prevent tampering. For example, when the service 
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platform is started, a coded check sum for files is compared to a reference (e.g., 
created upon installation or subsequent updating) If the comparison reveals possible 
tampering, a note is made in a log file which can be monitored remotely. 

5 In the presently contemplated embodiment, several types of fee or financial 

management arrangements may be provided in parallel. Firstly, a service 
subscription may exist for certain levels of service. The service subscription may 
time out periodically or may be permanent, such as Ufetime or non-expiring 
warranty service. Secondly, certain of the services provided remotely may be 

10 offered on a pay-per-use basis. In such cases, the logic of Fig. 15, or other financial 

management logic may be triggered upon generation of a service request, receipt of 
the service request, or fiilfillment of a service order. Finally, certain services or 
service data may be provided based on a purchase arrangement, in which the 
diagnostic system operator orders service or data and the associated fee is invoiced 

15 or debited to the diagnostic system accoxmt. Such arrangements may be employed, 

for example, for the transfer of new examination protocols, soflware, and so forth. 

The logic of Fig. 15 begins at step 352 with the triggering of a subscription 
check. As used herein, the term subscription should be understood to encompass 

20 both ongoing and periodically expiring Hcenses, pay-per-use arrangements, purchase 

arrangements, and other service and distribution arrangements. As illustrated in Fig. 
15, step 352 will generally occur at the diagnostic system. At step 354 a 
subscription manager module contained within the license module 114 of the 
diagnostic system is accessed. The subscription manager module will include data 

25 relating to specific applications or services to which the diagnostic system holds 

rights or subscriptions, as well as data relating to expiration dates, levels of service, 
system identification, and so forth. At step 356, the system determines whether the 
status of the various subscriptions is up-to-date or whether certain of the 
subscriptions may be expired. If any such problems with the service subscriptions is 

?0 detected at step 356, operation of the service platform or interface may be modified 

as indicated at step 358. Rather, or in addition to such modification in the service 
platform presentation or operation, a message may be generated and displayed at the 



35 



GEMS:0029 
15-SV-4769 



diagnostic system indicating the need to contact a field service engineer or the 
service faciUty, or to update the subscription. Following step 358, the service 
activities may continue as indicated at step 360. Step 360 is also reached where the 
status of the subscriptions checked at step 356 are found to conform to the needed 
5 status for the service activities desired by the user. 

Following the local verification of the subscription status, the diagnostic 
system may be connected to the service facihty as indicated at step 362. At step 364 
any service requests or messages composed at the diagnostic system may be 
10 transmitted to the service facility as described above. Based upon such service 

requests and messages, a finther subscription review may be performed in 
I conjunction with the service facility. In particular, as indicated at step 366, certain 

I of the service or data requests transmitted from the diagnostic system may require 

^ payment or authorization of a fee. Such requirements are identified at step 366. At 

115 step 368 a site subscription index maintained at the service facility is accessed. The 

\ site subscription index will typically be stored in a license database 146 (see Fig. 

^ 4A). The index includes up-to-date information regarding current subscriptions, 

- account data, system identification, authorization data, and so forth, for the specific 

^ diagnostic system and the services to which the diagnostic system either holds rights 

jlO or hcenses. The subscription index information is used by the service facility to 

update the data at the diagnostic system, as well as to authorize the requested 
service, or to perform accounting fimctions for debiting appropriate accounts for 
paid services. Where desired, subscription authorizations may also be automated 
between the service facility and diagnostic systems or medical institutions. 

25 

As indicated above, certain financial arrangements may be verified 
periodically either at the diagnostic system or by the service facility processing 
system. Step 370 in Fig. 15 indicates a periodic subscription check or status flag 
which may occur based upon such periodic license checking routines. When a 
30 periodic license check is triggered, the status of appUcable hcenses is verified at step 

372. If the statuses are current (e.g. no expired hcense flags are identified), normal 
operation may continue. However, where the status check indicates that certain 
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subscriptions have expired or will expire, the specific diagnostic system involved 
may be contacted by connecting to the service facility network as indicated at step 
374. Following the connection, the site subscription index is again accessed at step 
368 as summarized above. 

The site subscription index accessed at step 368 provides a basis for 
verifying and updating corresponding status data with the diagnostic system. Thus, 
at step 376, the subscription index is compared to similar subscription information 
stored at the diagnostic system, and it is determined whether an update is required. 
In general, it is presently contemplated that the master version of such information 
will be stored at the service facility, hi practice, portions of the indices or 
subscription files may be compared, or data derived from the indices or files may be 
compared for this purpose. Moreover, security devices may be included in the 
system to prevent unauthorized modification of the subscription data at the 
diagnostic system. Thus, if at step 376 the diagnostic system data is found not to 
conform to the information at the service facility, it is assumed that the diagnostic 
system is to be updated, and such updates are performed as indicated at step 378. 
Following either step 376 or 378, the status of the particular subscriptions are 
verified at step 380. This status verification may include, again, comparison of the 
current system subscriptions with the subscriptions necessary for the requested 
service. Moreover, the status check may verify whether the requested service is a 
pay-per-use service, a one-time fee service, and so forth. If the current subscription 
or financial arrangement is found to be in place at step 380, the system may continue 
with the handling of the service request as indicated at step 382. 

If at step 380 updating or fee authorization is required, a notification to this 
effect may be generated as indicated at step 384. Such notification will generally 
take the form of a message transmitted from the service facility to the diagnostic 
system as described above. Moreover, the notification may include one or more 
interactive pages for ordering or authorizing the required fee arrangement. Upon 
completion of such information or authorizations, the requested service may be 
ordered as indicated at step 386, Where the authorization is not received, the request 
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handling may be aborted at this stage. Upon transmission and receipt of the order or 
authorization data from the diagnostic system to the service faciUty, the service 
faciUty may perform verification routines as indicated at step 388, such as by 
comparing authorization codes with estabhshed codes stored v^ithin the subscription 
5 index. The subscription index is updated at step 390. Such updating will typically 

include indication of new expiration or renewal dates, addition of the authorization 
or fee arrangement to service history databases, and addition of the requested and 
authorized fees to accounting databases for debiting or invoicing purposes. Finally, 
once the required financial arrangement is estabhshed or verified, the handhng of the 
1 0 service request may continue as indicated at step 392. 

Fig. 16 illustrates exemplary logical steps for transmitting service and 
diagnostic programs from the service facility to diagnostic systems. As mentioned 
above, such programs may include new or revised examination sequences, 

15 protocols, and the like. While such protocols may be distributed on supports such as 

CD ROM discs, they may alternatively be suppUed via the network connection 
established between the service facility and the diagnostic systems. As used herein, 
the term program also refers to prerecorded or live transmissions such as video and 
audio transmissions employed by the facilities housing the diagnostic systems for 

20 personnel training purposes and the like. Such programs may be stored for 

distribution over a network as scheduled by the diagnostic system personnel, or may 
be prescheduled, such as through a preestabhshed training program or periodic 
training sessions. 

25 The logical steps depicted in Fig. 16, denoted generally by the reference 

numeral 400, begin with definition of the program at step 402. In general, and in 
particular for diagnostic system protocols, such programs will be defined 
specifically for the particular modality of the diagnostic systems, and, where 
appropriate with additional specificity according to the system type, model, and so 

30 forth. Such program content may be defined by the service facility or by other 

content providers. At step 404, the program is stored, such as in a database 156 or 
other storage device accessible to the service facility (see Fig. 4). 
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Several scenarios are presently envisioned for distribution of the programs 
via the service system described above. In particular, such programs may be 
distributed at the initiation of the service facility, or upon request by the diagnostic 
5 system. Where the service facility makes such programs available, the programs 

may be distributed via a "push" or "pull" scenario. In the former case, the programs 
are downloaded at the initiation of the service facility as described below. In the 
latter case, the diagnostic system is notified of the availability of the program, and 
may download or upgrade the system at will by recontacting the service facility. In 

10 either case, notiJScation is displayed at the diagnostic system through the interactive 

interface to inform the operations personnel of the availability or the presence of the 
program. For example, in the case of examination protocols, notification may be 
provided via the protocol page illustrated in Fig. 11, with the new examination 
protocol either stored locally at the diagnostic system, or available upon request 

15 from the service facility, or from a library or other resource to which the service 

faciUty or diagnostic system browser may connect the diagnostic system. Such 
connections may be implemented through conventional Uniform Resource Locator 
(URL) links. 

20 At step 406 of Fig. 16, the service facility processing system determines 

whether the program is to be distributed via a "push" or "pull" scenario. If the 
program is to be downloaded directly via a "push" scenario, subscription records are 
obtained from the service facility databases at step 408 to determine the present 
status of service subscriptions, and to compose a Hst of subscribing diagnostic 

25 systems to which the program is applicable and should be distributed. At step 410 

one or more messages to such systems are composed. Where programs are available 
or may be used by various system types or models, several messages may be 
composed at step 410 specifically adapted to the variations between the system 
types. Returning to step 406, where a "pull" scenario is to be employed for the 

30 program distribution, the subscription records of the service facility are again 

consulted at step 412 to develop a subscriber Hst to which the program should be 
made available. In general, such pull Usts may be compiled where specific 
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programs, including training sessions, protocols, and so forth, will be made available 
on a pay-per-use, one-time payment basis, or similar arrangements. At step 414, one 
or more messages are composed for the subscriber hst generated at step 412. From 
either step 410 or 414, the service facility may proceed to contact the diagnostic 

5 systems and to estabhsh the network connection described above, as indicated at 

step 416. At step 418 a message notifying the diagnostic system personnel of the 
existence and availability of the program is transmitted to the connected diagnostic 
system. Where the "push" distribution scenario is employed, step 418 may include 
loading of the program on the diagnostic system without requiring the intervention 

0 of the system operations personnel, but including notification of the presence of the 

new program. 



As mentioned above, in lieu of the service facihty-initiated distribution 
mechanism, the diagnostic system itself may originate program requests. Thus, as 

15 indicated at step 420, such request may be formulated, typically as a service request 

as described above. At step 422 a subscription requirement associated with the 
program may be checked, if such a requirement is stored locally at the diagnostic 
system. Where such a requirement is stored at the diagnostic system, the 
subscription manager module of the system may be accessed as indicated at step 

20 424, and the requirement and status compared as indicated at step 426. If the 

comparison made at step 426 determines that the program requires a subscription 
status or other arrangement or authorization which is not currently held by the 
diagnostic system, notification to the user is provided as indicated at step 428. From 
either step 426 or step 428, the system may continue with the program request 

25 procedure, or other interactive service procedures as noted at step 430, As 

mentioned above, such subscriptions, including for programs and protocols, may be 
of set to expire at particular times or after fixed durations, hi addition to the 
subscription verification, comparisons made at step 426 may include verifications of 
hardware or software configurations to ensure that particular programs or protocols 

30 are suitable for the requesting system. 
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Where the foregoing logic allows the diagnostic system to proceed with 
ordering the requested program, a connection is established at step 432 with the 
service facility. At step 434 the program request is transmitted, such as in the same 
manner as other service requests. At step 436 the service facility processing system 
5 may access the site subscription index, in much the same manner as described above 

with respect to the steps of Fig. 15 (see, e.g., step 368). The subscription index data 
is then compared with the similar data from the diagnostic system, as well as with 
requirements imposed by the particular program being requested. At step 438 this 
status is compared, and if additional subscriptions, data, or fee authorization is 

10 required, notification is provided via a return message to the diagnostic system as 

indicated at step 440. Where the foregoing steps permit transmission of the program 
according to the request, a message indicating its availabihty is transmitted at step 
41 8 as described above. Again, the message may be accompanied with the program 
data in accordance with a "push" scenario or may be transmitted at a subsequent 

1 5 time. 

Where the program data is transmitted at step 418, an installation step 
follows as shovra at step 442. The installation step may include expanding of 
program files, modification of resident files at the diagnostic system, enabling of 

20 software apphcations, and so forth. Where the requested program includes audio or 

video training sessions, other steps may be included at this installation stage, such as 
routing the requested program to a predetermined location or locations, hi addition 
to the installation step the subscription data, both at the diagnostic system and the 
service facility, is updated at step 444. For program distribution on such fee 

25 arrangements as pay-per-use, one-time payment, or expanded fee-based subscription 

services is provided, the updating performed at step 444 may include both updating 
of subscription manager and subscription index files, as well as updating of 
accounting files for debiting or invoicing the subscribers account. At step 446 the 
service facility may be disconnected from the diagnostic system. 

30 

As noted above, the interactive nature of the program distribution permits 
notification of the diagnostic system user by means of visual or auditory messages at 
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the diagnostic system. Thus, as indicated at step 448, a message is posted at the 
diagnostic system, indicating the availabiUty or transfer of the program at the 
initiation of the service facihty or in response to a request from the diagnostic 
system. Where the program is made available, but is not immediately transferred to 
the diagnostic system, a delayed transmission or subscriber "pull" step may be 
included as indicated at step 450. The logic involved in such delayed transmission 
v^ill typically follow the foregoing steps, including estabUshing a network 
connection between the diagnostic system and the service facility, verification of 
subscriber status, and transmission of the program. Once the program has been 
transmitted to the diagnostic system, it is installed as indicated at step 452. Again, 
the subscription data, both at the diagnostic system and at the service facility, is 
updated to indicate the current status of the program at step 454 as described above. 



42 



GEMS:0029 
15-SV-4769 



10 



CLAIMS: 

1. A system for servicing a medical diagnostic apparatus, the system 
comprising: 

a diagnostic apparatus including a service server for originating a service 
request and a network communications module for transmitting the service request; 

a service facility remote from the diagnostic apparatus, the service facihty 
including a network server for receiving the service request and exchanging data 
with the apparatus in response to the service request, 

2. The system of claim 1, wherein the diagnostic apparatus includes a 
network browser user interface for defining the service request originated by the 
server and transmitted by the network communications module. 



^15 3. The system of claim 1, further comprising a data storage device 

coupled to the network server, the data storage device storing service data 
^ representative of identifying or operational parameters of the diagnostic apparatus. 

I 4. The system of claim 1, wherein the service data includes data 

^- 20 representative of a apparatus type and location. 

5. The system of claim 1, further comprising at least one field service 
unit, the field service unit including a network browser and a network 
communications module for linking the field service imit to the service facility 

25 network server. 

6. The system of claim 1, wherein the service facility includes a 
messaging circuit configured to formulate and transmit a message to the diagnostic 
apparatus in response to the service request. 

30 
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7. The system of claim 1, wherein the service facility includes a 
scheduling circuit for scheduling service of the diagnostic system in response to the 
service request. 

5 8. An apparatus for providing service to medical diagnostic systems, 

the apparatus comprising: 

a plurality of medical diagnostic systems, each diagnostic system including a 
diagnostic station, a station interface for accessing data from the station, an operator 
interface for initiating service requests, and communications circuitry for 
1 0 transmitting and receiving data; and 

a service facility linked to the plurality of medical diagnostic systems via a 
C3 network, the service facility inchKiing a server for transmitting data to and receiving 

data from the pluraUty of medical diagnostic systems via the network. 

15 9. The apparatus of claim 8, wherein at least two of the plurality of 

1=1 medical diagnostic systems include stations of different modality types. 

10. The apparatus of claim 9, wherein the different modality types 
yl include magnetic resonance imaging stations, computed tomography stations, x-ray 

20 stations or ultrasound stations . 

11. The apparatus of claim 8, wherein at least two of the medical 
diagnostic systems are coupled to a management station via an intranet in a medical 
facility, and wherein the management station is linked to the service facility via the 

25 network. 

12, The apparatus of claim 8, wherein the communications circuitry is 
coupled to the station interface for transmitting data representative of station 
operating parameters to the service facility. 

30 

13, The apparatus of claim 8, wherein each diagnostic system includes a 
memory circuit for storing log data representative of serviceable conditions 
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occurring in the diagnostic system, and wherein the communications circuitry is 
coupled to memory circuit and transmits the log data to the service facihty. 

14. The apparatus of claim 13, wherein the log data is transmitted in 
response to a prompt from the service facihty. 

15. A system for remotely servicing medical diagnostic equipment, the 
system comprising: 

a first medical diagnostic station of a first modality, the first medical 
diagnostic station including a service server for accessing data representative of a 
serviceable condition of the first station; 

a second medical diagnostic station of a second modality different from the 
first modality, the second medical diagnostic station including a service server for 
accessing data representative of a serviceable condition of the second station; 

a service facility remote from the first and second stations, the service 
facility including a server for interactively exchanging service data with the first and 
the second stations. 



16. The system of claim 15, wherein the first and second modalities are 
selected from a group consisting of magnetic resonance imaging systems, computed 
tomography systems, x-ray systems and ultrasound systems. 

17. The system of claim 15, wherein the first and second stations each 
include an operator interface for initiating a service request and a communications 
circuit for transmitting the service request to the service facility. 

18. The system of claim 17, wherein the service facility server is 
configured to transmit an acknowledgment message to the first or the second station 
in response to a service request from the respective station. 

19. The system of claim 17, wherein the service facility server is 
configured to prompt data representative of a serviceable condition in response to a 
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service request from the first of the second station, and wherein the first and the 
second stations are configured to transmit the data representative of the serviceable 
condition in response to the prompt. 

5 20. The system of claim 15, v^herein the serviceable condition includes a 

malfunction in an imaging sequence in the first or the second station. 

21. The system of claim 15, v^herein the serviceable condition includes a 
request for operator useable information. 

10 

22. A method for providing remote service to a medical diagnostic 
system, the method comprising the steps of 

originating a service request in the medical diagnostic system via a user 
interface; 

15 transmitting the service request to a service facility via a network 

connection; 

acknowledging receipt of the service request automatically by the service 
facility via an electronic message to the medical diagnostic system. 

20 23. The method of claim 22, comprising the flirther step of transmitting 

data from the medical diagnostic system to the service facility representative of a 
potential malfunction of the medical diagnostic system. 

24. The method of claim 23, wherein the data is transmitted from the 
25 medical diagnostic system to the service facility in response to a prompt by the 

service facility, 

25. The method of claim 24, wherein the prompt is generated by the 
service facility automatically in response to the service request. 

30 
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26. The method of claim 22, comprising the further step of transmitting 
from the medical diagnostic system data representative of the diagnostic system type 
and identification. 

5 27. The method of claim 22, wherein the service request is generated 

through a preconfigured browser page accessible on the user interface. 

28. The method of claim 22, comprising the further step of displaying a 
visual indicia at the diagnostic system indicating receipt of the electronic 

1 0 acknowledgment message from the service facility. 

29. A method for exchanging service data between a plurality of medical 
diagnostic systems and a central service facihty, the method comprising the steps of: 

composing a service message on a medical diagnostic system; 
15 linking the medical diagnostic system to a remote service facihty via a 

network connection; 

transmitting the service message from the diagnostic system to the remote 
service facility; and 

automatically replying to the service message by the service facihty to the 
20 diagnostic system via a return electronic message. 

30. The method of claim 29, wherein the service message is composed 
via a user interface. 

25 31. The method of claim 29, wherein the service message includes data 

uniquely identifying the medical diagnostic system. 

32. The method of claim 31, comprising the further step of automatically 
accessing electronic records by the service facility in response to the service 
30 message. 
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33. The method of claim 32, wherein the electronic records include data 
representative of a subscriber status of the diagnostic system. 

34. The method of claim 32, wherein the electronic records include data 
5 representative of service history for the diagnostic system. 

35. The method of claim 29, comprising the further steps of: 
determining at the service center log data required to reply to the service 

message; 

10 automatically linking the service facility to the diagnostic system via a 

network connection; and 

transmitting the log data from the diagnostic system to the service center 

36. A method for servicing a plurality of medical diagnostic systems, the 
1 5 method comprising the steps of: 

generating a first service request message in a first diagnostic system of a 
first modality; 

generating a second service request message in a second diagnostic system 
of a second modality different from the first modality; 
20 transmitting the first and second service request messages to a service 

facility remote from the first and the second diagnostic systems; and 

transmitting an acknowledgment messages from the service facility to the 
first and second diagnostic system. 

25 37. The method of claim 36, wherein the first and second modalities are 

selected from a group including magnetic resonance imaging systems, computed 
tomography imaging systems, x-ray imaging systems and ultrasound imaging 
systems. 

30 38. The method of claim 36, including the fiirther step of displaying 

operator perceptible indicia at the first and second diagnostic systems indicating 
receipt of the acknowledgment messages. 
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39. The method of claim 36, wherein the first and second service request 
messages include data uniquely identifying the respective diagnostic system. 

40. The method of claim 36, comprising the further steps of: 
estabhshing a network link between the service facility and the first and the 

second diagnostic system; and 

transmitting parameter data from the diagnostic systems to the service 
facility, the parameter data including information indicative of a serviceable 
condition. 

41 . The method of claim 36, comprising the further steps of: 
estabhshing a network link between the service facility and the first and 

second diagnostic systems, and 

transmitting service data jfrom the service facility to the first and second 
diagnostic systems in response to the service request message. 

42. The method of claim 41, wherein the service data includes 
configuration parameter data for the diagnostic system. 

43. The method of claim 41, wherein the service data includes operator 
instructions adapted to the modality of the respective diagnostic system. 

44. The method of claim 36, wherein the service facihty includes a 
plurality of service facilities disposed at locations remote from one another. 
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ABSTRACT OF THE DISCLOSURE 

A system is provided for remotely servicing medical diagnostic systems. 
The diagnostic systems may include a range of modalities and system types. A 
remote service facility may be contacted by the diagnostic systems, or may contact 
5 the diagnostic systems via a network link. Service requests, messages, protocols, 

data and log files, and so forth, may be transmitted between the diagnostic systems 
and the service facility. The service requests are handled by the service faciUty 
interactively with the medical diagnostic systems. The diagnostic systems are 
thereby apprised of the status of service requests, service reports, and so forth. A 
10 uniform interface and platform are provided for facilitating interactive 

communications of service requests and data between the diagnostic systems and 
the service facility. 



50 




FIG. 4A 



FIG. 4B 




+ 




+ 



+ 



FIG. 6 



178 



r 

no 



□ □ 




^180 

C SERVICE A 
V REQUEST J 


^190 




"^^182 

(^APPLICATIONS^ 

. ^/^184 

f SYSTEM X 
V REPORTS J 
^^186 

MESSAGES J 
( HELP ) 

1 oo 


MOST RECENT MESSAGE 




WHEN: WED JUL 29 17:15:45 CDT 2000 

WHO: OLC, AUTOMATIC ACKNOWLEDGEMENT 

MESSAGE : YOUR REQUEST FOR A SERVICE 
ENGINEER HAS BEEN RECEIVED. 
YOUR REFERENCE NUMBER IS: 
123456 




NEW MESSAGES: 1 




f CLOSE J 









+ 



+ 



FIG. 7 



r 

178 

r 

192 



□ □ 




APPLICATIONS 
/.194 

f MAIN ^ 
V SCREEN J 


REMOTE 
SERVICE 

TIPS & WORKAROUNDS 
PROTOCOL 

DESCRIPTION: DESCRIPTIONS OF THE DEFAULT 


/-ISO 

f SERVICE ^ 
V REQUEST J 

^196 
^DOCUMENTS ^ 
^198 

C PROTOCOLS J 
Q HELP ^ 


PROTOCOLS ON YOUR SYSTEM. 

TIPS 

NEWSLETTER: TIPS ON HOW TO USE 
YOUR SYSTEM. 

FREQUENT 

QUESTIONS: 20 MOST FREQUENTLY ASKED 
QUESTIONS ABOUT YOUR 
SYSTEM TYPE. 

WORKAROUNDS- TIPS AND RFI FA'^F MCYTF^ ARnilT 
YOUR SYSTEM TYPE. 

\ 

200 



+ 



+ 



FIG. 8 



□ □ 



SERVICE REQUEST 



REMOTE SERVICE 



...YOUR FASTEST CONNECTION TO A REMOTE SERVICE ENGINEER... 



( MAIN \ 
^ SCREEN J 

^^194 



180 



C SERVICE A 
V REQUEST J 



178 



SERVICE CENTER 
PHONE 



HELP ^ 



r 

202 



REASON FOR CONTACTING SERVICE FACILITY: 



URGENT 
PROBLEM 



XAPPS 
QUESTION 
— 



5 



204 

PROBLEM AREA 

O PRESCRIPTION OARCHIVAL O IMAGE QUALITY 
O ACQUISITION OFILMING OOTHER 
O DISPLAY O NETWORKING 



206 



SUBMITTER 
PHONE 



SELECT NAME 



SELECT PHONE NUMBER 



OTHER: 
OTHER: 



IMAGE (EXAM /SERIES /IMAGE) ==>E 
PROBLEM DESCRIPTION: 



|s[ 



210 



111 



PROBLEM DATE /TIME: 



8 /27 /OO 13:21 



■214 



SEND TO 
SERVICE CENTER 



216 



+ 



+ 



FIG. 9 



□ □ 



SYSTEM REPORTS 



REMOTE SERVICE 



± 



194 



MAIN 
SCREEN 



3 



220 



C SERVICE 
V HISTORY ) 



^224 



SYSTEM 
USAGE 



228 



TUBE USAGE 



( 

178 



225 



MONITORING^ 
HELP ~^ 



218 



SERVICE HISTORY 



222 



DESCRIPTION 


TYPE 


REFERENCE 
NUMBER 


DATE 


PM WAS COMPLETED. 


FE 


12345678 


MAY 24 2000 


SYSTEM DISK IS FULL. 


REMOTE 


910111213 


JUN 09 2000 


GANTRY TEMPERATURE ADJUSTMENT 


FE 


141516171 


JUN 22 2000 


MAGNET WAS FILLED. 


MAGNET 
MONITORING 


81920212 


JUL 03 2000 



+ 



+ 



FIG. 10 



178 



r 

230 



MESSAGES 



REMOTE SERVICE 



2± 



194 



MAIN 
SCREEN 



CURRENT A 
^ MESSAGES J 




SAVED 
MESSAGES 



HELP 



3 
3 



CURRENT MESSAGES 



SUBJECT 



SOURCE 



DATE 



PM COMPLETED. 



AUTOMATIC SERVICE MESSAGE 
AUTOMATIC SERVICE MESSAGE 



07 /22 /00 17:55 
07 /29 /OO 07:12 



REPORTS AVAILABLE. 

> REFERENCE NUMBER ASSIGNED. CONTACT SERVICE CENTER RESPONSE 07 /29 /OO 17:15" 

DATE: WED JUL 29 17:15:45 CDT 2000 
SOURCE: "CONTACT SERVICE CENTER" RESPONSE 

MESSAGE: 

YOUR REQUEST FOR A SERVICE ENGINEER HAS BEEN RECEIVED. 
YOUR REFERENCE NUMBER IS: GJD092265 

YOU SHOULD RECEIVE A RESPONSE FROM AN ENGINEER WITHIN 
FIVE (5) MINUTES. 



( SAVE ^ DELETE ^ 



234 



232 



+ 



FIG. 11 



CLICK ON THE IMAGE OF THE DESIRED PROTOCOL 




□ □ 



REMOTE 
SERVICE 



DESCRIPTION OF PROTOCOL NO. 1 ^ 
AND PARAMETERS 



DESCRIPTION OF PROTOCOL NO. 2 
AND PARAMETERS 



DESCRIPTION OF PROTOCOL NO. 3 
AND PARAMETERS 



DESCRIPTION OF PROTOCOL NO. 4 
AND PARAMETERS 



DESCRIPTION OF PROTOCOL NO. 5 
AND PARAMETERS 



DESCRIPTION OF PROTOCOL NO. 6 
AND PARAMETERS 



238 



-240 



-240 



■240 




240 



+ 



FIG. 12 



250- 



252 



254 



256- 



258- 





ACCESS SERVICE PAGE 








CHECK SUBSCRIBER STATUS 








- DIAL AND CONNECT 










COMPOSE SERVICE REQ. 





264 



266- 




270 



- PLACE MESSAGE IN QUEUE 


268 






TRANSMIT 








RECEIVE ACKNOV\/LEDGEMENT 



272 
274^ 



TRANSMIT DATA 



DISPLAY MESSAGE 



276. 



278 



DISCONNECT 



\ < 

j RECEIVE DATA PULL REQUEST, 
I ACCESS STORED FILES & SEND 





^262 


YES 


LOCATE AND 




STORE DATA 



+ 



282 



2:^ 

RECEIVE REQUEST 



284 



DISPATCH \^N0 

OPEN 
? 



288 



304- 




DISPATCH NO 
ASSIGNED 

YES^ 



CREATE DISPATCH 



306 



SEND 


MESSAGE 


WITH 


STATUS 



308 



\J POP-UP BOX TO 
ASSIGNED ENG. 




280 



FIG. 13 



290 



APPEND 
NOTE 



286 



CREATE DISPATCH 
PLACE IN QUEUE 



292 



SEND MESSAGE 
WITH NO. /STATUS 



294 



NOTIFY MODALITY 
SERVICE ENG. 



296 



AUTO 


CALLBACK 


FOR 


SERVICE 




DATA 



298 



ACCESS, TRANSMIT, 
STORE DATA 



300 



CONNECT TO 
SERVICES FACILITY 
DATABASE 



302 



ACCESS, TRANSMIT, 
STORE DATA 



+ 



312 



FIG. 14 



SITE REPORT 
REQUEST 



316 



^ TRANSMIT REQUEST 



318 



320 



ACKNOWLEDGE 



324 



322 



FEE FOR\^NO 
REPORT 
? 

fVES 



PERFORM 
FEE /SUBSCR. 
LOGIC 



CONNECT TO SYSTEM 



■328 



SWEEP FOR DATA 



330 



TRANSMIT SYS. DATA 



332 







UPDATE SERVICE DATA 



334 



DISCONNECT 



336 



PROCESS DATA 



/ 



310 



338 



340- 



COMPLETE REPORT 



CONNECT & NOTIFY / 
PUSH REPORT 



342- 



SITE/FE PULL 
REPORT 



^314 

FE REPORT 
REQUEST 



326 



PERIODIC 
TRIGGER 



370 



FIG. 15 



TRIGGER S UBSCRIP. SWEEP 



ACCESS SITE SUBSCRIP. MANAGER 



SUBSCRIP. CHECK 
STATUS FLAG 



355 




CONNECT 



378 



UPDATE 



382 



"In 



CONTINUE 



360 




CONTINUE 



CONNECT 



•362 



TRANSMIT SERV. REQ./MESS. 



ACCESS SUBSCRIP. REQ'M'T 



ACCESS SITE SUBSCRIP. INDEX 




NOTIFY 



I 



ORDER 



VERIFY 



384 



386 
—388 



UPDATE SUBSCRIP. INDEX 



I 



CONTINUE 



392 



352 
354 



358 



MODIFY /MESSAGE 



'364 

■366 

-368 



390 



350 



+ 



FIG. 16 

402 



400 



^ 



DEFINE PROGRAM 



404 



I 



^ STORE PROGRAM 



412 




DETERMINE 
SUBSCRIP. STATUS 




420 
422- 
424--. 



REQUEST PROGRAM 



I 



CHECK SUB SCRIP. REQ'MT 



ACCESS SUBSCRIP. MANAG. 



PUSH 



I 



408- 







DETERMINE 
SUBSCRIP. STATUS 




428 



NOTIFY 



COMPOSE 
MESSAGE(S) 



414 



7 



410- 



COMPOSE 
MESSAGE(S) 



416 



I 



CONTINUE 



CONNECT 



I 



— 430 
432 



-434 



TRANSMIT PROGRAM REQUEST 



CONNECT 



ACCESS SITE SUBSCRIP. INDEX 



^436 




440 



NOTIFY 



448 



POST MESSAGE 



450. 



I 



452 



454 



DELAYED SEND OR 
SUBSCRIBER PULL 

lEI — 

^Tnstall j 



442 



TRANSMIT MESSAGE 
(AND PROGRAM) 



444. 



,_[N£rALL I 



3 



UPDATE SUBSCRIP. DATA 



446- 



DISCONNECT 

ZZ] — 



r 



UPDATE SUBSCRIP. DATA 



+ 



PATENT 

DOCKET NO.:15-SV-4769 
GEMS:0029 



COMBINED DECLARATION AND POWER OF ATTORNEY 
FOR PATENT APPLICATION 

As the beiow-named inventors, we hereby declare that: 

Our residences, post office addresses and citizenship are as stated below next to our names. 

We believe we are the original, first and joint inventors of the subject matter which is claimed and 
for which a patent is sought on the invention entitled: MEDICAL DIAGNOSTIC SYSTEM SERVICE 
METHOD AND APPARATUS, the specification of which is attached hereto. 

We hereby state that we have reviewed and understand the contents of the above-identified 
specification, including the claim, as amended by any amendment referred to above. 

We acknowledge the duty to disclose information which is material to the examination of this 
application in accordance with Title 37, Code of Federal Regulations, §1 .56(a). 

We hereby claim foreign priority benefits under Title 35, U.S.C. §1 19 of any foreign application for 
patent or inventor's certificate listed below, and have also identified below any foreign application for 
patent or inventor's certificate having a filing date before that of the application on which priority is 
claimed: 



COUNTRY 


APPLICATION NUMBER 


DATE OF FILING 

(day, month, year) 


PRIORITY CLAIMED 
UNDER 37 U.S.C. 119 


None 














□ Yes □ No 



We hereby claim the benefit under Title 35, United States Code, §120 of any United States 
application(s) listed below and, insofar as the subject matter of each of the claims of this application is not 
disclosed in the prior United States application in the manner provided by the first paragraph of Title 35, 
United States Code, §112, I acknowledge the duty to disclose material information as defined in Title 37, 
Code of Federal Regulations, §1. 56(a) which occurred between the filing date of the prior application and 
the national or PCT international filing date of this application: 



APPLICATION SER. 
NO. 


APPLICATION SER. 
NO. 


FILING DATE 


STATUS (patented, pending, 
abandoned) 


None 









We hereby appoint Christian G. Cabou (Reg. No. 35,467) and Phyllis Y. Price (Reg. No. 34,234) 
both of GE Medical Systems, 3000 North Grandview Blvd., Waukesha, Wisconsin 53188; Ronald E. 
Myrick (Reg. No. 26,315) and Henry J. Policinski, (Reg. 26,621) both of General Electric Company (W3E), 
3135 Easton Turnpike, Fairfield, Connecticut 06431-0001; and Patrick S. Yoder (Reg. No. 37,479), 
Michael G. Fletcher (Reg. No. 32,777), and Robert A. Van Someren, (Reg. No. 36,038) of Fletcher, Yoder 
& Van Someren, 7915 FM 1960 West, Suite 330, Houston, Texas 77070, jointly, and each of them 
severally, our attorneys, with full power of substitution, delegation and revocation, to prosecute this 
application, to make alterations and amendments therein, to receive the patent and to transact all 
business in the Patent and Trademark Office connected therewith. 



Page 1 of 3 



We hereby direct that all correspondence and telephone calls in connection with this application 
be addressed to Patrick S. Yoder, 7915 FM 1960 West, Suite 330, Houston, Texas 77070, (281) 970- 
4545, 

We hereby declare that all statements made herein of our own knowledge are true and that all 
statements made on information and belief are believed to be true; and further statements were made with 
the knowledge that willful false statements and the like so made are punishable by fine or imprisonment, 
or both, under Section 1001 of Title 18 of the United States Code and that all such willful false statements 
may jeopardize the validity of the application or any patent issued thereon. 



Full name of first joint inventor: Kenneth Lawrence AccardI 

Inventor's signature: ^)^Lyr^A■^^^ (Xckx^^U. Date: ///^3 / 
Residence: N18 W30050 Crooked Creek Road, Pewaukee, Wl 53072 
Citizenship: The United States of America 
Post Office Address: same as residence 



Full name of second joint inventor: Deborah Ann Babula 

Inventor's sionature: Dj^Hy[^ (} Bnhu . Date: ^l/^dMB 
Residence: 8282 Four Oaks Drive, Franklin, Wl 53132 
Citizenship: The United States of America 
Post Office Address: same as residence 



Full name of third joint inventor: George Peter Gesior 
Inventor's signature: 



Residence: 731 Crestwood Drive, Waukesha, Wl 53188 
Citizenship: The United States of America 
Post Office Address: same as residence 



Page 2 of 3 



Full name of fourth joint inventor: htenry John Hummel, Jr. 




Inventor's sianature: ^^ 4^/-*-tryy^^^ Date: j^-/^0V-l99X 



Residence: 1905 Cro%|^w^Coyj?tn/Va)j^sha W 
Citizenship: The Unitec 
Post Office Address: same as residence 



Full name of fifth joint inventor: lanne Mae Howards Koritzinsky 

Inventor's signatog? -n^/ fiuLj 

Residence: 2626 \^est Hunter Circle, Giendale Wl 53209 

Citizenship: The United States of America 

Post Office Address: same as residence 



Full name of sixth joint invent9j::;^Scott Matt McOlash 




Inventor's sianature: ^>:>^^""^X^^ Date: 

Residence: 2431 North 82"^ Street, Wauwatosa Wl 53213 
Citizenship: The United States of America 
Post Office Address: same as residence 



Full name of seventh joint inventor: George Tzortzos 



Inventor's signature: 



ASjf Date: lljli/^ 



Residence: 17230 Robinwood Street, Brookfield Wl 53045 
Citizenship: The United States of America 
Post Office Address: same as residence 



Full name of eighth joint inventor: Hubert Anthony Zettel 



Inventor's signature: /^.J^L-^hM^ Date:_ 



Residence: W225 S4375 Guthrie Ro^^iWaukesha Wl 53189 
Citizenship: The United States of America 
Post Office Address: same as residence 



Page 3 of 3 



